Re: [heycam/webidl] Consider [LegacyStringClass] (#547)

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