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 obj.foo 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:
http://wiki.ecmascript.org/doku.php?id=strawman:object_model_reformation#implementing_built-in_array_semantics_without_using_proxy
>
> 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.
Allen
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
