extracting namespace from a property

Yuh-Ruey Chen maian330 at gmail.com
Thu Mar 1 10:01:10 PST 2007

Brendan Eich wrote:
> On Mar 1, 2007, at 6:19 AM, Yuh-Ruey Chen wrote:
> > In standard mode, every class (except maybe host objects) are dynamic,
> > right? Or at least would every builtin class is dynamic in standard  
> > mode?
> The built-in classes defined in ES3 section 15 are dynamic, but class  
> B extends A {} by default is not dynamic. You can have non-dynamic  
> subclasses of a dynamic class (necessary since Object is the base  
> class of all others and it's dynamic).
> IIRC you are allowed to have a dynamic subclass of a non-dynamic  
> superclass (Jeff correct me if I'm wrong). dynamic is not inherited,  
> and applied to a class, it affects only mutability of instances  
> (whether one can add "expandos", i.e. whether the class "seals"  
> instances), again if my memory is correct. Others should correct me  
> or add more information as needed.
> Standard vs. string mode does not change the default for a class that  
> lacks an explicit 'dynamic' qualifier.

So a classes' prototype is always going to be mutable?

In chapter 9, I see "Prototype objects are always instances of the
dynamic class Object and therefore can always be extended by the
addition of dynamic properties. Unlike with function closures which have
a prototype property that is a variable and can be reset to another
object, classes have a prototype that is read-only and so always points
to the same object."

which to me says that although the prototype property is read-only for
classes, the referenced prototype object can still be mutated.

> I've changed the proposal to say that typeof n === "string"; we'll  
> see how that flies.
> > I guess it depends
> > on how much you're willing to break.
> There's a fine line. If typeof n == 'string' is not helpful, then I  
> would prefer to make typeof n == 'object'. Spidering the visible web  
> can only produce counter-examples showing how we might help someone  
> with an incompatible "bug fix" -- it can't prove that we won't break  
> someone else

typeof name === "object" would be backwards compatible with ES3 if there
are no enumerable qualified properties that are present on any builtin
object. For ex, although the proposed iterator::get would be a property
of Object, it's not enumerated and so no name object for it would be
created in the default enumerator.

It only becomes an issue once a custom enumerable qualified property is
added by the author. So maybe we should let typeof name === "object" and
just warn developers to use |is| if they intend to enumerate over
objects with enumerable qualified properties.


More information about the Es4-discuss mailing list