Re: DOMString-like objects for the CSSOM

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.


> 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.


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

Received on Friday, 19 February 2010 16:11:45 UTC