Re: DOMString-like objects for the CSSOM

On Fri, Feb 19, 2010 at 7:48 AM, Anne van Kesteren <> wrote:

> On Fri, 19 Feb 2010 16:44:05 +0100, Mark S. Miller <>
> wrote:
>> How do you propose your new DOMString-like object be represented in
>> JavaScript?
> As an object but with indexOf, substring, ...

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

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.

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

> --
> Anne van Kesteren


Received on Friday, 19 February 2010 16:06:34 UTC