Lecture series on SES and capability-based security by Mark Miller
axel at rauschma.de
Fri Nov 4 20:38:59 PDT 2011
> I agree completely (see also my other email):
> - Never use objects as maps.
> - Introduce collection classes.
> - Try to make arrays fit into the collection framework.
> Great! But could you please post a pointer to that other email, or post a summary? Thanks.
This is the original thread:
My understanding (using Allen’s terminology) is as follows (consult Allen’s email that started the thread for further details and a longer rationale).
We have to separate the data domain from the program domain:
- Arrays:  is used to access both collection/array elements (data domain) and properties (program domain).
- Objects:  is used mainly for properties, but also for collection element access when (ab)using objects as maps from strings to values.
1. New operator for the data domain: Introduce a new, separate operator . for accessing collection elements. Use it for all new collection types, implement it for arrays, too.
2. Rededicate  to be used for the data domain only: Default behavior remains as is, but can be overridden in collection classes (including arrays). Using  for property access is deprecated, you must use methods such as Object.setOwnProperty() and Object.getProperty() to do so.
Addendum: edited quote from a recent email of mine:
> I think it’s better to rededicate  to be a collection element accessor:
> - Introducing . would deprecate all existing array code and code that uses objects as maps.
> - Rededicating  would only deprecate code that uses computed property names.
> It might make sense to have a "stricter mode" that turns off the default behavior of :
> - It would thus force you to use methods such as (the yet to be defined) Object.setOwnProperty() and Object.getProperty() when you want to compute the name of a property.
> - Stricter mode could also restrict  for arrays to just numbers, including negative numbers for accessing elements relative to the end of an array.
Dr. Axel Rauschmayer
axel at rauschma.de
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss