names [Was: Approach of new Object methods in ES5]

David Herman dherman at mozilla.com
Fri Apr 16 11:31:07 PDT 2010


> Name sounds like a stripped-down uninterned symbol (http://bit.ly/bY3Jkg) to me.

Yup.

> It's an object with a magic attribute that says, unlike any other object you might try to use it as a property name, it is not coerced into a string first.  And it is compared by identity when looked up.  And it is invisible to (all?) enumerations of property names.

Yup again. Basically it entails a slight generalization of the property lookup semantics; instead of ToString there would be a ToPropertyName meta-operation, which for existing ES objects would just delegate to ToString, but for the new class of things would be the identity.

> I have to wonder if it would be a worthwhile generalization to be able to confer these magical attributes on arbitrary objects?  This might allow more experimentation with namespace ideas.

This is worth exploring. I'd worry about unintended consequences of an attribute that can be turned on/off at will. But even if it were fairly restricted -- e.g., you could turn it on but you couldn't turn it back off again -- it might be more powerful.

Tucker: if the "property-nameness" attribute weren't transferrable but names were objects with property tables, do you think that would be powerful enough? Or would you want the ability to define custom constructors, e.g.:

    function MyCustomKindOfNamespace() {
        Object.becomePropertyName(this);
        // ...
    }

Dave

PS Still, I have my doubts about using any such mechanisms for versioning. Incidentally, ROC was just talking about versioning and metadata on the web:

    http://weblogs.mozillazine.org/roc/images/APIDesignForTheMasses.pdf

He wasn't talking about JS API design, but some of the lessons still apply.



More information about the es-discuss mailing list