shortcuts for defining block-local private names, plays nicely with @foo syntax

Allen Wirfs-Brock allen at
Mon Jan 23 08:43:21 PST 2012

On Jan 22, 2012, at 7:36 PM, Tab Atkins Jr. wrote:
> ...
> I have a question, that may be an objection.  In my blog post
> <>, I demonstrate several example
> usages of Names.  Most of them involve using a Name that's hung off of
> another object.  Is there a way to support this pattern without a
> temporary variable?

I agree, this is another common use case that I should have mentioned in my message.

An alternative to handing such private names off of object is to export them as const bindings from a module.  You can see an example of this style in 

> For example, from my post:
> myCoolObject.prototype[Iterator.getIterator] = function(){...}
> Using @ for access, would
> "myCoolObject.prototype. at Iterator.getIterator = function(){...}" work,
> or would that attempt to retrieve a property using "Iterator" as a
> Name, then retrieve the "getIterator" property of that?
> If the latter, this is rather inconvenient for what I expect will be
> common patterns.

   myCoolObject.prototype. at Iterator.getIterator

parses as:  ((myCoolObject.prototype). at Iterator).getIterator

which probably is not what you desire.

Taking just what is in my basic proposal, you would have to express this using a local variable:

const getIterator = Iterator.getIterator;
myCoolObject.prototype. at getIterator = function() {...}

If @( ) is allowed for property keys in object literals you could say:

obj = {
   @(Iterator.getIterator): function () {...}

or using concise method syntax just

obj = {
   @(Iterator.getIterator) () {...}

however if we want to directly use Iterator.getIterator as the key in a member expression we would need to enable use of @()  as the property name in a member expression:

myCoolObject.prototype.@(Iterator.getIterator) = function () {...}

I'm still ambivalent whether we actually need this.  I think I like the module export pattern slightly better and might prefer to encourage that.

Another possible extension would be to allow private declarations of the form:

    private getIterator = Iterator.getIterator;

this really would mean exactly the same as an equivalent with const (perhaps the initializer might be throw if it doesn't evaluate to a private name) but it emphasizes the intended usage.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list