Strawman: Decouple [ ] and property access
I've posted a new strawman proposal for the ideas originally discussed in this thread.
Feedback:
- I like contrasting the concept “application data domain” with the concept “program definition domain”. Maybe mention that earlier.
- Typo: “Updated WeapMap and Map Interface”
- Mention best practices: when to use what (might have time until an actual implementation).
StringKeyedMap.prototype. at elementGet = function(k) {return this. at backingStore[k]} => That is still the “an object as a programming construct” style (include prototypes) and not the “an object as a collection” style (only own properties).
Possible change (with a yet-to-be-defined method Object.getOwnProperty()): StringKeyedMap.prototype. at elementGet = function(k) {return Object.getOwnProperty(this. at backingStore, k)}
I’m not sure how one can best keep the two styles apart, perhaps @elementGet should use Object.setProperty() instead of square braces.
I've posted a new strawman proposal for the ideas originally discussed in this thread.
I forgot: +1
On Thu, Nov 10, 2011 at 4:58 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
I've posted a new strawman proposal for the ideas originally discussed in this thread. strawman:object_model_reformation Allen
A comparison to 'dict' which shares the expressed goals of the above proposal would be a great addition. Roughly speaking it appears to be "more ambitious than", meaning more effort and more power.
jjb
thanks, a good suggestion.
Actually they are quite different. The dict proposal is simply defining one new data types that can be used as a key value store which is guaranteed not to have any pre-existing key conflicts prior to initial use.
My proposal, defines a general extensible mechanism that JS programmers can use to define many kinds of new collection abstractions all of which use a consistent accessing syntax whose semantics is completely under the control of the programmer.
That the [] decoupling is needed can by seen by the fact that dicts can’t have a size() method (as opposed to the dictionary solution in the strawman).
I implemented this for Traceur last week. The abstraction is leaky since Traceur does not have private names yet but it is still good enough for a demo.
traceur-compiler.googlecode.com/svn/trunk/example/collection.html
Instead of private names we just use Object.define*
+1 !!
I've posted a new strawman proposal for the ideas originally discussed in this thread.
strawman:object_model_reformation