JavaScript Language feature Idea

Andy Earnshaw andyearnshaw at gmail.com
Mon Apr 18 18:58:06 UTC 2016


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, <joe at trusktr.io> 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 <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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160418/5925c4c1/attachment-0001.html>


More information about the es-discuss mailing list