I don't think that would be trivial to implement and there might not be a common enough use case for it. You might want to look into something like http://sweetjs.org if it's the syntactic sugar you're looking for.
On Mon, 18 Apr 2016 19:35 /#!/JoePea, <[email protected]> wrote: > > ```js > > Array[Symbol.implementation] = MyArray; > > ``` > > > That would mean all other programs executing on the page would be forced > to use that Array implementation > > And also with my suggestion that would impact all code too. > > Would it be possible to limit the effect of using certain symbols to a > scope where the symbol is used? For example: > > ```js > function main() { > Array[Symbol.implementation] = MyArray; > > let a = [1,2,3] // uses MyArray > } > let a = [1,2,3] // uses Array > main() > ``` > > or > > ```js > Array[Symbol.implementation] = MyArray; > function main() { > let a = [1,2,3] // uses MyArray, from outer scope > } > let a = [1,2,3] // uses MyArray > main() > ``` > > Or maybe some other method on a per-scope basis? > > On Mon, Apr 18, 2016 at 11:25 AM, Andy Earnshaw <[email protected]> > wrote: > > That would mean all other programs executing on the page would be forced > to > > use that Array implementation, imposing potentially critical problems > with, > > for example, performance and expected behavior. It's just not a good > idea. > > > > I missed off esdiscuss when I replied earlier, but I mentioned that the > only > > reasonable solution is to introduce new syntax, e.g. > > > > myArray[:-1] > > > > However, it's been said that there needs to be a compelling reason to add > > new syntax and I'm not sure this qualifies imo. > > > > > > On Mon, 18 Apr 2016 19:11 kdex, <[email protected]> wrote: > >> > >> Yes, now we're heading in the right direction. > >> > >> The problem with something like `Symbol.propertyAccess` is that this > might > >> lead to a flood of new well-known Symbols. > >> Conceptually, `Symbol.propertyAccess` sounds like it should have been a > >> `Proxy` trap, anyway. > >> > >> Here's an more general idea: Why not allow users to set a derived class > >> for literals via well-known Symbols? > >> Thus, users could provide custom implementations for `RegExp`, `Array`, > >> `Object` (…) literals, as long as the value points to a derived class. > >> > >> We could even introduce negative array indices in a way that doesn't > break > >> the web like this: > >> > >> ```js > >> [1, 2, 3][-1]; // undefined > >> Array[Symbol.implementation] = MyArray; > >> [1, 2, 3][-1]; // 3 > >> Array[Symbol.implementation] = 3; // TypeError: Array implementations > must > >> extend Array (→ Array.isPrototypeOf(Number(3)) is false) > >> ``` > >> > >> On Montag, 18. April 2016 10:47:24 CEST /#!/JoePea wrote: > >> > But, can > >> > > >> > ```js > >> > let a = [1,2,3] > >> > ``` > >> > > >> > create a new MyArray? Maybe, instead of having negative indices by > >> > default (which breaks some backwards compatibility) we can introduce a > >> > symbol for overriding property access? Something like > >> > > >> > ```js > >> > Array.prototype[Symbol.propertyAccess] = function(index) { > >> > if (index < 0) ... > >> > else ... > >> > } > >> > ``` > >> > > >> > ? Just an idea; I'm not sure if that's a good use for Symbols. We > >> > could then easily add this helper code to a given app. > >> > > >> > On Mon, Apr 18, 2016 at 10:25 AM, kdex <[email protected]> wrote: > >> > > I don't see a good reason why to mangle with this. > >> > > Note that you can achieve this behavior without breaking backwards > >> > > compatibility with ES6 Proxies: > >> > > > >> > > ```js > >> > > class MyArray extends Array { > >> > > constructor(...args) { > >> > > super(...args); > >> > > function computeProperty(target, property) { > >> > > const index = +property; > >> > > return index < 0 ? String(target.length + > >> > > index) : property; > >> > > } > >> > > return new Proxy(this, { > >> > > get(target, property, receiver) { > >> > > return Reflect.get(target, > >> > > computeProperty(target, property), receiver); > >> > > }, > >> > > set(target, property, receiver) { > >> > > return Reflect.set(target, > >> > > computeProperty(target, property), receiver); > >> > > } > >> > > }); > >> > > } > >> > > } > >> > > ``` > >> > > > >> > > On Montag, 18. April 2016 09:59:15 CEST /#!/JoePea wrote: > >> > >> Backwards compatibility has been broken before. I don't think this > >> > >> one > >> > >> is too bad of a breakage. > >> > >> > >> > >> On Sun, Apr 17, 2016 at 9:48 PM, Biju <[email protected]> > wrote: > >> > >> > On 17 April 2016 at 17:29, Frankie Bagnardi < > [email protected]> > >> > >> > wrote: > >> > >> >> That would break backward compatibility; > >> > >> >> > >> > >> >> ```js > >> > >> >> var a = ['a']; > >> > >> >> a['-1'] = 'test'; > >> > >> >> Object.keys(a) // ['0', '-1'] > >> > >> >> ``` > >> > >> > > >> > >> > Do we have statistics how many sties depend on that? > >> > >> > _______________________________________________ > >> > >> > es-discuss mailing list > >> > >> > [email protected] > >> > >> > https://mail.mozilla.org/listinfo/es-discuss > >> > >> _______________________________________________ > >> > >> es-discuss mailing list > >> > >> [email protected] > >> > >> https://mail.mozilla.org/listinfo/es-discuss > >> > >> > >> > > _______________________________________________ > >> > > es-discuss mailing list > >> > > [email protected] > >> > > https://mail.mozilla.org/listinfo/es-discuss > >> > > >> _______________________________________________ > >> es-discuss mailing list > >> [email protected] > >> https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
