On 2007-10-21, at 15:20 EDT, Brendan Eich wrote: > On Oct 21, 2007, at 11:48 AM, Jeff Dyer wrote: > >>> The wrapper classes String, Number, Boolean are similar to the >>> (primitive) values they wrap, but they're not really related to >>> those >>> value types in a type sense, and in ES4 the wrappers are of even >>> less >>> utility than in ES3, I would say. >>> >> >> Right, thanks for the correction. This is an obvious consequence of >> the >> recent return of primitive wrappers to ES4. 'string' is the new >> 'String'! > > String has its uses, not just embedded in content that requires > compatibility: string and String inter-convert, String is non-final, > and the two share a prototype object.
I think Dylan would have made String an open subclass of the sealed class string: http://www.opendylan.org/books/dpg/db_305.html > The need for string comes directly from ES1-3, because the primitive > string type in JS1 was auto-wrapped when you used a string value as > if it were an object, say to call a method on it. But since a new > wrapper was created each time (or so it appeared; implementations > could optimize), the object-ness of the primitive string was > ephemeral: you couldn't set methods and get them later; any get on > the wrapper for a property not found on String.prototype or above > would return undefined. > > In ES4, string has catchalls to satisfy this ephemeral wrapper get/ > set compatibility, but method calls on string instances do not > require String wrapper creation. Are you saying for compatibility you have to maintain this 'ephemeral wrapper' behavior? > Wrapper creation may or may not be observable in ES3 -- 9.9 says > "create a new String" but does not say by evaluating |String| in > order to construct -- but ES4 does not allow any type name to be re- > bound, so the implementations that chose to construct the wrapper by > reflecting on the current value of 'String' in the global object, > thereby allowing someone to replace that binding and spy on wrapper > construction, no longer need to reflect each time. > > The shared prototype object allows for replacement of prototype > methods, which per ES1-3 and much compatibility-constraining content > on the web, remain mutably bound in the shared prototype object. Thus > in ES1-3, if you wrapped String.prototype.charAt with some AOP advice > function, your code calling "hi".charAt(0) will still run your advice. > > Since ("hi instanceof String) was never true, it should not be true > in the new world. This is one reason string and String are peer > subtypes of Object, that is, string is not a subtype of String. IWBNI there were a single test for string-ness. In ES3, you have to say: typeof x == 'string' || (typeof x == 'object && x instanceof String) Am I right in thinking that in ES4 you will be able to say: x is string to ask the same question? > Tucker and others have hoped for a way to customize String, and since > it is non-final and convertible to string, the use-cases that want to > make custom objects that delegate to String.prototype should work > too. But it would be good to see some examples. My use case is for an annotated string, the result of a sprintf-like formatter that remembers the objects associated with each representation (so you can inspect a message for more detailed information): http://svn.openlaszlo.org/openlaszlo/trunk/WEB-INF/lps/ lfc/debugger/LzMessage.lzs _______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
