On Jan 23, 2012, at 7:43 PM, Axel Rauschmayer wrote:
>> Also, the square bracket preference also currently shows up in the object
>> literal computed property key proposal so we already have
>> obj[privateNameValue] pattern manifesting itself as new ES6 syntax.
>
>
> Would [] in object literals still make sense if [] was to become a data-only
> operator?
>
Perhaps, but not with its current proposed meaning. Assume you have already
defined a prototypal object Dictionary, then it might be useful to create
literal instance of it by saying something like:
let myDict = Dictionary <| {
["key1"]: 1,
[computedKey()]: 2,
[var]: 3
};
For that to work, the individual element definitions would have to desugar into
@elementSet method calls on the new object and Dictionary would presumably have
defined @elementSet.
This might be combined with regular property definitions, for example:
let myDict = Dictionary <| {
["key1"]: 1,
[computedKey()]: 2,
[var]: 3,
initialLength: 3
};
However, things would break down if you wanted to add a private named property
using the current obj lit computed property name proposal:
const myTradeMark = name.create();
let myDict = Dictionary <| {
["key1"]: 1,
[computedKey()]: 2,
[var]: 3,
initialLength: 3,
[myTradeMark]: true
};
As [myTradeMark]: true would create a dictionary element instead of a property.
To get around this we would need a different way to define private named
properties in object literals, such as:
const myTradeMark = name.create();
let myDict = Dictionary <| {
["key1"]: 1,
[computedKey()]: 2,
[var]: 3,
initialLength: 3,
@myTradeMark: true
};
I'm not convinced that this style of literal is actually that practical
considering that many collection abstractions would need to initialize their
instances before inserting elements and it isn't clear how that initialization
would occur for such literals.
Regardless, if we want to ever have a reformed object model where [ ] can be
defined to mean element access we probably shouldn't also depend upon [ ] for
private named property definition considering that any object that redefines [
] is going to have to define and probably invoke the private named
elementGet/elementSet methods. Consider the
http://wiki.ecmascript.org/doku.php?id=strawman:object_model_reformation#a_string_keyed_map
example. If @. wasn't available to use to reference private named properties
something like explicit Object.getProperty calls would have to be used instead
and it would look like:
module Name from "@name";
import {elementGet, elementSet, elementDelete} from Name;
import iterator from "@iter";
const backingStore = Name.create();
export function StringKeyedMap() {
Object.setProperty(this,backingStore) = Object.create(null); //note
@backingStore object is a "normal object" and [ ] on it does regular property
access
}
Object.setProperty(StringKeyedMap.prototype,elementGet) = function(k) {return
Object.getProperty(this,backingStore)[k]}
Object.setProperty(StringKeyedMap.prototype,elementSet) = function(k,v)
{Object.getProperty(this,backingStore)[k]=v;}
StringKeyedMap.prototype.size = function()
{Object.getOwnPropertyNames(Object.getProperty(this,backingStore).length};
//I'm lazy
StringKeyedMap.prototype.has = function(k) {return
{}.hasOwnProperty.call(Object.getProperty(this,backingStore),k};
Object.setProperty(StringKeyedMap.prototype,elementDelete) = function(k)
{return delete Object.getProperty(this,backingStore)[k]}
Object.setProperty(StringKeyedMap.prototype,iterator) = function() {
// iteration yields key/value pairs
let self = this;
let backing = Object.getProperty(this,backingStore);
return (function*() {for (let x in backing) {if (self.has(x)) yield [x,
backing[x]]}})();
}
Much less pleasant than the original example using @.
Allen_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
