- From: Domenic Denicola <notifications@github.com>
- Date: Thu, 12 Apr 2018 00:57:22 +0000 (UTC)
- To: heycam/webidl <webidl@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <heycam/webidl/issues/547/380640903@github.com>
My take is that this is probably not a great idea. String objects are generally confusing and a "mistake" in JavaScript (it would have been better to just have lowercase-s string primitive values). But, let's explore a bit... Probably the best thing to do is figure out what programmer-facing experience you'd be able to achieve here. I can think of a few things: - Allow use in contexts that expect a string-like. This is doable without inheriting from String: just add a toString() method to SVGAnimatedString. (Maybe it already has one?) Every context on the web platform and the JS standard library will automatically work in this case. - Allow use of String.prototype methods, like substring/startsWith/etc. For example, `a.href.substring(1)`. This would be what requires inheriting from String. But, how would these work? E.g. would substring() return a SVGAnimatedString, or a String, or a string? Would they operate on animVal or baseVal? - Not possible: have `typeof a.href === "string"` It will be `"object"` instead. - Not possible: have `a.href === otherA.href` even if their "real values" are equivalent. They will always be different objects, so will be `!==`. Similarly, you won't be able to ever make `a.href === "some string literal"` work. (Although you could make `==` work... but nobody uses that.) Maybe there are more... will ask around/think harder. My general takeaway is that you're most likely to land yourself in a weird uncanny valley by inheriting from `String`, and there's no real good solution here. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/heycam/webidl/issues/547#issuecomment-380640903
Received on Thursday, 12 April 2018 00:57:49 UTC