Re: Re: Proposal: Symbol Linked to `typeof`

[Randy Buchholz]

Your Absolutely right! My mistake.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Proposal: Symbol Linked to `typeof`

[Augusto Moura]

The module system is not filesystem based, but URL based, that's a lot
of differences between the two, URLs are designed to be unique and be
storage/protocol agnostic in most networks. Others languages are
following similar paths, Go for example even allows you to import
entire github projects directly in source code, Deno (a experimental
Node-like platform, made by the Node former creator) follows the same
direction. In a distributed world, URLs work really good as truly
Global Unique Identifiers

In my opinion there's no better way to uniquely identifying than
comparing it with the actual reference. But if you want a qualified
name so badly, the only way I know is writing them manually, maybe you
could use some external tool to automate this step, something like
jscodeshift or a babel plugin. You could use decorators for runtime
injection metadata (probably a parameterized namespace name)

``` js

const rootNamespace = 'com.foo'

const qualifiedName = (...namespaces) => (clazz) => {
  const namespacesJoined = namespaces.join('.');
  clazz.qualifiedName = rootNamespace + (namespacesJoined ? '.' +
namespacesJoined : '') + '.' + clazz.name;
};

@qualifiedName('domain', 'package')
class Foo {
}

console.assert(Foo.qualifiedName === 'com.foo.domain.package.Foo')
```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Proposal: Symbol Linked to `typeof`

[Randy Buchholz]

@Augusto Moura, I like the approach using `hasInstance`.

It may be just me, but having your software architecture hardcoded to your 
filesystem (even with logical roots) feels shaky. (and so 1970’s ). Namespaces 
serve the purpose you stated at compile/runtime, but also serve as a form of 
human readable GUID for classes at design time, and allow creating a logical 
hierarchy independent of storage. This could be helpful for things like “object 
servers”/DI approaches. If I expose a service to deliver ES Classes, I don’t 
want users to know or depend on how I store them. ES is awesomely dynamic in 
every way except the hardcoded paths. Really, underlying the proposal is 
wanting to uniquely identify my classes with a token. As much for design-time 
as run-time. Currently, I expose a static GUID in all of my classes.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Proposal: Symbol Linked to `typeof`

[Jordan Harband]

https://github.com/michaelficarra/proposal-first-class-protocols may be
relevant.

On Wed, Jan 16, 2019 at 9:06 AM Augusto Moura 
wrote:

> I don't think string namespaced names are the right feature here
>
> Namespaces are intended mainly to avoid conflicts with names when
> sharing a global scope (like when using classpath in Java, or libs in
> C++)
> Javascript already solves this problems with modules, you can always
> guard your code with instanceof and the right instance of your class,
> you don't need "qualified names"
> ``` js
> // flow.js
> export class Flow {
> }
> ```
> ``` js
> // main.js
> import { Flow } from './flow.js'; // we don't need namespaces, a "file
> path" already resolves conflicts for us
>
> const doSomething = (obj)  => {
>   if (obj instanceof Flow) {
> // ...
>   }
> }
> ```
>
> You can also customize the instanceof operation with `Symbol.hasInstance`
> ``` js
> class Flow {
>   // Normally you would check the minimum contract required to any guard
> work
>   // Probably bad idea to override in most of the cases
>   static [Symbol.hasInstance](obj) {
> return '_flow' in obj;
>   }
> }
>
> // Note that the control is inverse to your proposal the Class
> determines if a value is instance (this why it's static)
> // Without altering `Flow[Symbol.hasInstance]` just expected objects
> will pass the check in `doSomething`
> doSomething({}); // doesn't work
> doSomething({ __proto__: Flow.prototype }); // doesn't work
> doSomething({ _flow: undefined }); // actually works
> ```
>
> ~string qualified names are so 20th century~
>
>
> Em qua, 16 de jan de 2019 às 01:48, Randy Buchholz
>  escreveu:
> >
> > Right. Misappropriating a symbol corrupts its intent. As ES moves in a
> more towards a more “class-ish” feel, and people start writing more
> classes, a type/namespace system isn’t far behind. Implementing some
> symbols to support this helps drive some standard approaches and
> discourages symbol misappropriation.
> >
> >
> >
> > ___
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
>
>
>
> --
> Atenciosamente,
>
> Augusto Borges de Moura
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Named de-structuring arguments.

[Mark]

oof. I appreciate how terse it is, but the readability of it all is a bit
scary when you're doing multiple assignments more than one level deep.

-m


On Wed, Jan 16, 2019 at 3:28 AM Jordan Harband  wrote:

> See https://github.com/zkat/proposal-as-patterns
>
> On Wed, Jan 16, 2019 at 12:24 AM Sultan  wrote:
>
>> The ability to both name and de-structure an argument.
>>
>> Relying on the spread operator does not archive the same effect
>> considering that the spread operator "by design" has some short-comings
>> related to exotic objects when the objects in question have a rich
>> prototype you want to preserve.
>>
>> Consider the following proposal:
>>
>> function fn (arg pick {a, b = arg.b = 'value'}) {}
>>
>> This would allow four fundamental things of note missing from current
>> de-structuring status-quo:
>>
>> 1. The ability to have both named arguments and de-structuring.
>>
>> 2. The ability to reference the named argument within the de-structure.
>> This allows the above pattern of setting a default value on the passed
>> argument when it doesn't exist.
>>
>> 3. This in turn also affords you the ability to de-structure while also
>> preserving the exotic nature of an object when it is not a POJO object.
>>
>> That is when "arg" is an exotic use-defined object using the spread
>> operator "{...arg}" will discard its prototype.
>>
>> For example:
>>
>> function a ({a, ...b}) { return b }
>>
>> a([1, 2])
>>
>> Returns a object with index-able keys instead of the array.
>>
>> 4. Consequently this addition would also afford the avoidance of any
>> overhead that one might want to avoid with the rest spread operation: {a,
>> b, ...arg} in hot paths.
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Proposal: Class Templates

[Jordan Harband]

https://github.com/michaelficarra/proposal-first-class-protocols may be a
more palatable approach here.

On Wed, Jan 16, 2019 at 9:41 AM ViliusCreator 
wrote:

> Also, using `new (Abc(4, 5, 6))(1, 2, 3)` causes error ` Uncaught
> TypeError: Abc(...) is not a constructor`.
>
>
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_-2762429988630184872_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Proposal: Class Templates

[ViliusCreator]

Also, using `new (Abc(4, 5, 6))(1, 2, 3)` causes error ` Uncaught TypeError: 
Abc(...) is not a constructor`.



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Proposal: Class Templates

[ViliusCreator]

You could use
```js
new Abc`abc`(‘abc’)
```
But you could only use strings. What about constructors? You would need to use
```js
const thatConstructor = (new Function(‘return ’ + t))()
```
But it would only give what is defined in that constructor.


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Proposal: Symbol Linked to `typeof`

[Augusto Moura]

I don't think string namespaced names are the right feature here

Namespaces are intended mainly to avoid conflicts with names when
sharing a global scope (like when using classpath in Java, or libs in
C++)
Javascript already solves this problems with modules, you can always
guard your code with instanceof and the right instance of your class,
you don't need "qualified names"
``` js
// flow.js
export class Flow {
}
```
``` js
// main.js
import { Flow } from './flow.js'; // we don't need namespaces, a "file
path" already resolves conflicts for us

const doSomething = (obj)  => {
  if (obj instanceof Flow) {
// ...
  }
}
```

You can also customize the instanceof operation with `Symbol.hasInstance`
``` js
class Flow {
  // Normally you would check the minimum contract required to any guard work
  // Probably bad idea to override in most of the cases
  static [Symbol.hasInstance](obj) {
return '_flow' in obj;
  }
}

// Note that the control is inverse to your proposal the Class
determines if a value is instance (this why it's static)
// Without altering `Flow[Symbol.hasInstance]` just expected objects
will pass the check in `doSomething`
doSomething({}); // doesn't work
doSomething({ __proto__: Flow.prototype }); // doesn't work
doSomething({ _flow: undefined }); // actually works
```

~string qualified names are so 20th century~


Em qua, 16 de jan de 2019 às 01:48, Randy Buchholz
 escreveu:
>
> Right. Misappropriating a symbol corrupts its intent. As ES moves in a more 
> towards a more “class-ish” feel, and people start writing more classes, a 
> type/namespace system isn’t far behind. Implementing some symbols to support 
> this helps drive some standard approaches and discourages symbol 
> misappropriation.
>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss



--
Atenciosamente,

Augusto Borges de Moura
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Class Templates

[Augusto Moura]

In the proposal:
> ``` js
> class SizedArray extends Array {
>
>   constructor(...args) {
> if(args.length > size) throw new SyntaxError('Argument size is too big.')
> super(...args)
>   }
>   push(i) {
> if(this.length + 1 > size) throw new SyntaxError('Cannot push items 
> anymore, array too big.')
> super.push(i)
>   }
> }
> ```
> Usage:
> Usage is simple, and obvious.
> ``` js
> // ...
> let somethingElse: A = new A;
> ```

I don't think the syntax is obvious. What will happen in the if inside
the constructor? What value `size` would receive? Infinity? undefined?
The `Number` function?
That's no way templates will ever work like that in Javascript, it
doesn't makes any sense, C++ templates were implemented to support
generic static allocation and safe typings, neither of this features
applies to Javascript (and probably never will). Your example could
easily be written with constructor arguments (like any sane OOP
language), that's not a problem to be solved here

``` js
class SizedArray extends Array {
  constructor(size, ...args) {
if (args.length > size) throw Error();
super(args);
  }
}
```

Em ter, 15 de jan de 2019 às 17:01, IdkGoodName Vilius
 escreveu:
>
> See: 
> https://github.com/CreatorVilius/ecmascript-proposals/blob/master/proposal-class-templates.md
>
>
>
> I think having Class Templates in JavaScript would be awesome thing and 
> should be implemented. But that’s just my opinion.
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss



-- 
Atenciosamente,

Augusto Borges de Moura
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Class Templates

[Claude Pache]

> Le 16 janv. 2019 à 13:57, ViliusCreator  a écrit 
> :
> 
> “Strongly typed” Strongly typed is not Statically typed. Python is strongly 
> typed for example. Strongly typed language means that `”something” + 1` will 
> throw error, Weakly typed means that `”something” + 1` will turn `1` into 
> string and add it to `something`, which will result in `something1`.
> 
> Statically typed language means that once you do `Boolean Abc = true`, or 
> `let Abc: Boolean = true`, you can’t change it to number, but you can change 
> it to `false`, or `true`.
>  
> Did you mean Statically typed language?
> 
> Also, I think that there can be usefulness in class templates, without 
> language being Statically typed.

I meant ”statically typed”, yes. But I think you understood what I meant. My 
question was about compelling use cases in JS. We know that you think it is 
useful, but you should convince others that it is useful, that is to say, worth 
the added complexity in the language.

 —Claude___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Proposal: Class Templates

[T.J. Crowder]

On Wed, Jan 16, 2019 at 1:01 PM ViliusCreator
 wrote:
>
> Yes, you can do that. But then doesn’t that look ugly?
>
> `new (Abc(1, 2, 3)(4, 5, 6)`, vs `new Abc<4, 5, 6>(1, 2, 3)`.

You meant `new (Abc(4, 5, 6))(1, 2, 3)` vs. `new Abc<4, 5, 6>(1, 2, 3)`,
right? There's not a *lot* in it... :-)

The problem you face is that `new Abc<4>(1, 2, 3)` (where there's only one
thing within the <>, presumably a common case) is already valid syntax:

* `new Abc<4>(1, 2, 3)` becomes
* `o<4>(1, 2, 3)` becomes
* `b1>(1, 2, 3)` becomes
* `b1>3` becomes
* `b2`

...where `o` is the object created by `new Abc` (parens are optional in
`new` if there are no arguments), `b1` is the boolean resulting from `o<4`,
and `b2` is the boolean resulting from `b1>3`.

Even though nearly-nonsensical, assigning valid syntax new meaning is a
very high barrier to jump. (Interestingly, if *weren't* the case that `<`
after `new Identifier` is already valid syntax, the spec changes to enable
making `new Abc` call Abc with x and then use new on the result [no need
to tie it specifically to some "class templates" concept] would be fairly
small [tagged templates already work that way]. But...) You'd need `new
Abc<|4|>` or similar, and...that seems like it's unlikely to happen.

I want to reach for tag functions here, but it would be either **ugly**:

```js
new Abc`${4}${5}${6}`(1, 2, 3)
```

...or an awful and limited hack...

```js
new Abc`4, 5, 6`(1, 2, 3)
```

(parsing the "arguments" in the template from the strings array passed to
the tag function).

`new (Abc(4, 5, 6))(1, 2, 3)` starts looking pretty good. :-)

-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Proposal: Class Templates

[ViliusCreator]

Yes, you can do that. But then doesn’t that look ugly?
`new (Abc(1, 2, 3)(4, 5, 6)`, vs `new Abc<4, 5, 6>(1, 2, 3)`.



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Proposal: Class Templates

[ViliusCreator]

“Strongly typed” Strongly typed is not Statically typed. Python is strongly 
typed for example. Strongly typed language means that `”something” + 1` will 
throw error, Weakly typed means that `”something” + 1` will turn `1` into 
string and add it to `something`, which will result in `something1`.

Statically typed language means that once you do `Boolean Abc = true`, or `let 
Abc: Boolean = true`, you can’t change it to number, but you can change it to 
`false`, or `true`.

Did you mean Statically typed language?

Also, I think that there can be usefulness in class templates, without language 
being Statically typed.


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Class Templates

[Michał Wadas]

Isn't it already solvable by:

const SizedArray = (size) => class SizedArray extends Array
 {

  constructor(...args) {
if(args.length > size) throw new SyntaxError('Argument size is too big.')
super(...args)
  }
  push(i) {
if(this.length + 1 > size) throw new SyntaxError('Cannot push
items anymore, array too big.')
super.push(i)
  }

}

const arr = new (SizedArray(5))?



On Tue, Jan 15, 2019 at 8:01 PM IdkGoodName Vilius <
viliuskubilius...@gmail.com> wrote:

> See:
> https://github.com/CreatorVilius/ecmascript-proposals/blob/master/proposal-class-templates.md
>
>
>
> I think having Class Templates in JavaScript would be awesome thing and
> should be implemented. But that’s just my opinion.
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

[no subject]

[IdkGoodName Vilius]

"Strongly typed"? You mean statically typed? Python is both dynamically and
strongly typed. Strongly typed, meaning "str" + 123 will throw error,
weakly typed would turn number to string.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Class Templates

[Isiah Meadows]

Also, it's worth mentioning Julia exists as language precedent here: it's
got generic runtime types in the form of both classes and type aliases,
despite being a dynamically typed, JIT-compiled language.
On Wed, Jan 16, 2019 at 04:54 Isiah Meadows  wrote:

> Reflection would be nice, but that's about the only use case I can think
> of. Being able to tell a typed number array from a typed object array would
> be useful for some array processing optimizations and maybe stream
> processing optimization, but that's about it AFAIK.
> On Wed, Jan 16, 2019 at 04:42 Claude Pache  wrote:
>
>> From what I understand (that is, not much), class templates are useful in
>> strongly typed languages, so that one can have a family of classes that
>> share the same implementation but that derive from different types; e.g.
>> Stack for stacks of ints and Stack for stacks of strings. In
>> JS, you can have one Stack class that accepts both ints and strings, so
>> that this use case doesn’t apply (or, at least, it is not a necessity).
>>
>> But I'm sure there are other use cases. What are they, and are they
>> compelling enough?
>>
>> —Claude
>>
>> Le 15 janv. 2019 à 19:59, IdkGoodName Vilius 
>> a écrit :
>>
>> See:
>> https://github.com/CreatorVilius/ecmascript-proposals/blob/master/proposal-class-templates.md
>>
>>
>> I think having Class Templates in JavaScript would be awesome thing and
>> should be implemented. But that’s just my opinion.
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Class Templates

[Isiah Meadows]

Reflection would be nice, but that's about the only use case I can think
of. Being able to tell a typed number array from a typed object array would
be useful for some array processing optimizations and maybe stream
processing optimization, but that's about it AFAIK.
On Wed, Jan 16, 2019 at 04:42 Claude Pache  wrote:

> From what I understand (that is, not much), class templates are useful in
> strongly typed languages, so that one can have a family of classes that
> share the same implementation but that derive from different types; e.g.
> Stack for stacks of ints and Stack for stacks of strings. In
> JS, you can have one Stack class that accepts both ints and strings, so
> that this use case doesn’t apply (or, at least, it is not a necessity).
>
> But I'm sure there are other use cases. What are they, and are they
> compelling enough?
>
> —Claude
>
> Le 15 janv. 2019 à 19:59, IdkGoodName Vilius 
> a écrit :
>
> See:
> https://github.com/CreatorVilius/ecmascript-proposals/blob/master/proposal-class-templates.md
>
>
> I think having Class Templates in JavaScript would be awesome thing and
> should be implemented. But that’s just my opinion.
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Class Templates

[Claude Pache]

From what I understand (that is, not much), class templates are useful in 
strongly typed languages, so that one can have a family of classes that share 
the same implementation but that derive from different types; e.g. Stack 
for stacks of ints and Stack for stacks of strings. In JS, you can have 
one Stack class that accepts both ints and strings, so that this use case 
doesn’t apply (or, at least, it is not a necessity).

But I'm sure there are other use cases. What are they, and are they compelling 
enough?

—Claude

> Le 15 janv. 2019 à 19:59, IdkGoodName Vilius  a 
> écrit :
> 
> See: 
> https://github.com/CreatorVilius/ecmascript-proposals/blob/master/proposal-class-templates.md
>  
> 
>  
> I think having Class Templates in JavaScript would be awesome thing and 
> should be implemented. But that’s just my opinion.
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Named de-structuring arguments.

[Jordan Harband]

See https://github.com/zkat/proposal-as-patterns

On Wed, Jan 16, 2019 at 12:24 AM Sultan  wrote:

> The ability to both name and de-structure an argument.
>
> Relying on the spread operator does not archive the same effect
> considering that the spread operator "by design" has some short-comings
> related to exotic objects when the objects in question have a rich
> prototype you want to preserve.
>
> Consider the following proposal:
>
> function fn (arg pick {a, b = arg.b = 'value'}) {}
>
> This would allow four fundamental things of note missing from current
> de-structuring status-quo:
>
> 1. The ability to have both named arguments and de-structuring.
>
> 2. The ability to reference the named argument within the de-structure.
> This allows the above pattern of setting a default value on the passed
> argument when it doesn't exist.
>
> 3. This in turn also affords you the ability to de-structure while also
> preserving the exotic nature of an object when it is not a POJO object.
>
> That is when "arg" is an exotic use-defined object using the spread
> operator "{...arg}" will discard its prototype.
>
> For example:
>
> function a ({a, ...b}) { return b }
>
> a([1, 2])
>
> Returns a object with index-able keys instead of the array.
>
> 4. Consequently this addition would also afford the avoidance of any
> overhead that one might want to avoid with the rest spread operation: {a,
> b, ...arg} in hot paths.
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Proposal: Named de-structuring arguments.

[Sultan]

The ability to both name and de-structure an argument.

Relying on the spread operator does not archive the same effect considering
that the spread operator "by design" has some short-comings related to
exotic objects when the objects in question have a rich prototype you want
to preserve.

Consider the following proposal:

function fn (arg pick {a, b = arg.b = 'value'}) {}

This would allow four fundamental things of note missing from current
de-structuring status-quo:

1. The ability to have both named arguments and de-structuring.

2. The ability to reference the named argument within the de-structure.
This allows the above pattern of setting a default value on the passed
argument when it doesn't exist.

3. This in turn also affords you the ability to de-structure while also
preserving the exotic nature of an object when it is not a POJO object.

That is when "arg" is an exotic use-defined object using the spread
operator "{...arg}" will discard its prototype.

For example:

function a ({a, ...b}) { return b }

a([1, 2])

Returns a object with index-able keys instead of the array.

4. Consequently this addition would also afford the avoidance of any
overhead that one might want to avoid with the rest spread operation: {a,
b, ...arg} in hot paths.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss