extracting namespace from a property

[Yuh-Ruey Chen]

Brendan Eich wrote:
> > Well as I mentioned, although Name would derive from String, it would
> > still have to redefine all of String's methods.
>
> Not so -- see ES1-3, where String.prototype methods except for  
> toString and valueOf are intentionally generic. They convert their  
> this parameter ToString and then operate on the result of that  
> internal type conversion call.
>
> > This implies that any
> > method added to String's prototype would not automatically work with a
> > Name instance. Unless the way Name delegates String methods via some
> > __noSuchMethod__/__resolve__ hook.
>
> Generic methods on String.prototype automatically work, where "work"  
> is defined as operate on ToString(n), without hassle. If one adds a  
> specific String.prototype method that can't cope with Name, but  
> operates on its |this| parameter only if that parameter is exactly a  
> string instance already, then it will throw when called on Name --  
> which will tell the programmer to extend Name.prototype too (if we do  
> decide to make class Name be dynamic).
>   

Ah, I totally forgot about string methods being generic (AFAIK there's
practically no code out there that has a constructor whose prototype is
String or has a String method as a property of a non-String object).

In standard mode, every class (except maybe host objects) are dynamic,
right? Or at least would every builtin class is dynamic in standard mode?

> >> Given Name <: String, it makes sense for (typeof n === "string")
> >> given (n is Name).
> >>
> >
> > Does this mean that in ES4 typeof Object(string) == "string"  
> > instead of
> > "object" (and for other primitive wrappers)?
>
> That would have been the case if we had managed to merge string  
> primitive type with String object wrapper, but we can't, so what  
> happens instead is the same as today:
>
> js> typeof Object('hi')
> object
> js> Object('hi') instanceof String
> true
>
> > Since Name instances are
> > objects, typeof name should be "object", unless objects and their
> > primitive counterparts have been unified with respect to typeof.
>
> typeof new Name('hi') === "object", as you would expect.
>
> We can't merge string and String, etc.
>
> /be
>   

Hmm...that will be troublesome in the case where a key is passed to a
function that tries to check if the passed argument is a string only via
typeof:

function foo(x) {
    if (typeof x == 'string') {
       // if x is a Name, we won't get here
    }
}

for (k in o) foo(k);

Of course, the function should have |x instanceof String|. But if the
program was designed so that it guaranteed that it never passed String
objects to foo, and foo is passed keys within a for-in loop, and that
for-in loop was iterating over an object containing a qualified
property, we run into backwards compatibility trouble.

On the other hand, the |typeof null == 'null'| change is more likely to
break backwards compat, yet that's currently in ES4. I guess it depends
on how much you're willing to break.

New ES4 code would typically use the |is| operator anyway, and
primitives and wrappers are unified under |is|, right?

-Yuh-Ruey