Re: DOMString-like objects for the CSSOM

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

> On Fri, 19 Feb 2010 16:44:05 +0100, Mark S. Miller <erights@google.com>
> 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 <
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.)

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



-- 
    Cheers,
    --MarkM