>> 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 [email protected] home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
