`Symbol.implementation` should be fairly trivial to implement once [Realm](https://github.com/caridy/proposal-realms)s are around, without affecting global scope.
On Montag, 18. April 2016 18:58:06 CEST Andy Earnshaw wrote: > 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
