Re: DOMString-like objects for the CSSOM

On Fri, Feb 19, 2010 at 8:11 AM, Anne van Kesteren <annevk@opera.com> wrote:

> On Fri, 19 Feb 2010 17:06:03 +0100, Mark S. Miller <erights@google.com>
> wrote:
>
>> First, this wouldn't be string-like, it would be String-like. We generally
>> try to avoid wrappers, because of the annoying differences between wrappers
>> and primitives already noted: !, ===, typeof. Would you have your
>> String-like instances inherit from String.prototype? Would they inherit
>> from their own prototype that inherits from String.prototype? Or would they
>> inherit from a String instance containing their string? (Note that, since
>> the methods on String.prototype are intentionally generic, either would
>> actually work.)
>>
>
> Them having their own prototype as well would be nice.
>
>
>
>  Why make your new object be String-like rather than simply containing a
>> string as a member? Why use is-a rather than has-a? My sense is that, were
>> one thinking in JS terms rather than WebIDL terms, has-a for primitives
>> would seem a more natural choice. YMMV.
>>
>
> Yes, but then we would completely break the existing API. Unless I
> misunderstand what you mean.


Are you trying for compatibility with an API currently defined in terms of
DOMString? This is impossible in ES5 for the reasons already noted. No new
ES5 values can be LSP subtypes of strings. If they're not LSP subtypes, they
are not compatible.



>
>
>
>  None of this should be taken as an endorsement of JS's distinctions
>> between primitives and objects. I think we all agree in retrospect that this
>> difference was a mistake. But WebIDL hides the mistake when instead we
>> should be learning to live with it.
>>
>> (I should note that the Harmony value types strawman <
>> http://wiki.ecmascript.org/doku.php?id=strawman:value_types>, once worked
>> out, promoted from strawman to proposal, adopted, and deployed, should
>> enable the creation of string-like data types, just as it would allow the
>> creation of number-like data types. However, WebIDL is attempting to
>> define bindings for ES5, not possible Harmony futures.)
>>
>
> Interesting. I'm sure we'll update WebIDL as implementations progress.


Are you willing to postpone your new DOMString-like type until that future
day? If not, then its binding to ES would already be determined and could
not later be compatibly upgraded to bind to a value type.


>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>



-- 
    Cheers,
    --MarkM