JavaScript Language feature Idea

kdex kdex at kdex.de
Mon Apr 18 18:11:22 UTC 2016


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 <kdex at kdex.de> 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 <bijumaillist at gmail.com> wrote:
> >> > On 17 April 2016 at 17:29, Frankie Bagnardi <f.bagnardi at gmail.com> 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
> >> > es-discuss at mozilla.org
> >> > https://mail.mozilla.org/listinfo/es-discuss
> >> _______________________________________________
> >> es-discuss mailing list
> >> es-discuss at mozilla.org
> >> https://mail.mozilla.org/listinfo/es-discuss
> >>
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> 


More information about the es-discuss mailing list