JavaScript Language feature Idea

/#!/JoePea joe at trusktr.io
Mon Apr 18 18:35:17 UTC 2016


> ```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 <andyearnshaw at gmail.com> 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, <kdex at kdex.de> 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 <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
>> >
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss


More information about the es-discuss mailing list