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

Allen Wirfs-Brock allen at
Tue Jan 24 15:03:33 PST 2012

On Jan 24, 2012, at 12:35 PM, Axel Rauschmayer wrote:

>>> Reiterating my support for the reformed object model (ROM): I love how the ROM will finally end the clashes between application data (array elements, entries in objects-as-maps) and program definition (methods, non-method properties). It’s a nice clean-up, with a clear migration strategy.
>>> @() could take the place of [] for property access, if we allow string operands.
>> You realize this is a huge change that will break a lot of code, if done incompatibly. If you "do both" (only certain collections misbehave when using [] to access properties rather than collection data), you'll still have breakage -- and confusion.
>> I'm not saying we can't do OMR or whatever it ought to be called. But we should not require ocean-boiling, or make a "big red switch" problem.

This is all pretty much covered in the Object Model Reformation strawman proposal.  Nothing  in that proposal would change the behavior of any existing code.  What it does provide is the opportunity for ES programmer to define new object abstractions where [ ] means something different   from normal property access.  This is an opportunity that is already available and used by some  built-in and host object (particularly the DOM) authors.  The distinction between data element ([ ]) and property access would only exist for objects that explicitly define the differences.

However, an implication permitting the redefintion of [ ] on a per object basis is that and obj['foo'] are not always the same operation.  Whether that identify holds depends upon the definition of obj.  This is why the proposal was titled "Object Model Reformation" -- it requires ES programmers (over time) to start thinking of [ ] and property access as distinct operations that are not necessarily coupled to each other.  If we think there is a possibility that of moving in that direction then we should avoid introducing new idioms, such as using [ ] for private property access, that would be problematic for objects that decouple [ ] and property access.

> I’d leave Object and Array as is and introduce two collection types:

We must leave Object and Array as is.  However, it would be possible to reimplement the existing Array semantics in ES without needing to use Proxies: 

> 1.  List (or Sequence or something else): same interface as Array (hence array-like). No holes, indices are non-negative integers, etc.
> 2.  Map (possibly the SimpleMap that has already been specified).

One reason I introduced this the OMR strawman when I did is because we are already committed to adding new "collection" objects (Map, WeakMap, Set, and possibly others) to ES6 and that they currently have to use get/set method-based APIs.  Early adoption of OMR would allow these new kinds of collections to use [ ] for data element access.  I also suspect (but haven't worked through the details) that use of OMR could also improve inthe Binary Data/Typed Array abstractions. 

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

More information about the es-discuss mailing list