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

Axel Rauschmayer axel at rauschma.de
Tue Jan 24 12:35:54 PST 2012


>> 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.


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

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).

Both types would be recommended replacements (especially Map for Object-as-map) and separate elements/entries from properties (with obvious benefits – no shadowing, less tricky key enumeration).

Would that boil oceans?
- With OMR, swapping Arrays for Lists would be trivial, because you could keep using [] for element access.
- I’m not sure that arrays need to be replaced, but objects as maps are so difficult to handle that using something else is a must, IMHO.

-- 
Dr. Axel Rauschmayer
axel at rauschma.de

home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120124/95bffdce/attachment-0001.html>


More information about the es-discuss mailing list