And here's another sort of case where sparse arrays are useful, a more
concrete example:
A partial application function which takes a function (as the 'this'
argument in this example) and a (sparse) array specifying which parameters
to bind:
f.partial(['a', , 'b']) is then different from f.partial
A sparse array is useful whenever the index represents an externally
meaningful piece of data (like an ID).
This use case could be replaced with a Map which just uses integer keys,
but I believe JavaScript engines are better optimized working with Arrays
here, where the keys are known to be intege
No informative deed goes unpunished, especially (as in this case) if it has
contradictory normative implications! This was the lesson of ECMA-357 (E4X),
with its overdone informative prose which often contradicted the normative
prose.
/be
Sent from my iPad
> On Feb 21, 2014, at 3:29 PM, Allen
On Feb 21, 2014, at 3:16 PM, Brandon Benvie wrote:
> On 2/21/2014 3:08 PM, Allen Wirfs-Brock wrote:
>>> ```
>> Don't put too much weight into that. I've experiment with use the latter
>> style when define some new methods to see where it is helpfully more
>> descriptive. I just haven't bother t
On 2/21/2014 3:08 PM, Allen Wirfs-Brock wrote:
It might be worth coming up with good terms for "ES5-style optional
arguments" and "ES6-style optional arguments" which can be used
consistently in the spec. They can already be distinguished by
signature, ie:
```js
Array.prototype.reduce ( callba
On Feb 21, 2014, at 1:47 PM, C. Scott Ananian wrote:
> I wasn't confused by the spec text as is, but I'm not surprised that
> others are. The language is battling against two different "standards"
> for optional arguments. In ES5 typically "not present" is used; in ES6
> for consistency with the
I actually just responded in more depth over at
http://esdiscuss.org/topic/what-does-is-not-present-mean-in-spec-algorithms#content-9
Let's continue the discussion over there.
--scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozil
I wasn't confused by the spec text as is, but I'm not surprised that
others are. The language is battling against two different "standards"
for optional arguments. In ES5 typically "not present" is used; in ES6
for consistency with the new language optional arguments, "undefined"
is treated as "not
On Feb 21, 2014, at 1:15 PM, C. Scott Ananian wrote:
> There are a number of differences between ES5-style methods and ES6
> methods. This is unfortunate, but probably inevitable.
>
> * ES5 methods typically use "argument is present", while ES6 methods
> treat an undefined argument as the same
OK, we can discuss and report back. We'll definitely want to take into account
Guy's use case about being able to recognize module instance objects as such.
Dave
On Feb 21, 2014, at 12:53 PM, Allen Wirfs-Brock wrote:
>
> On Feb 21, 2014, at 12:08 PM, David Herman wrote:
>
>> I think it shoul
On Fri, Feb 21, 2014 at 9:49 AM, Brendan Eich wrote:
> Whatever we do, we should be consistent among sparse arrays and sparse
> arraylikes, it seems to me. Want a bug?
Filed https://bugs.ecmascript.org/show_bug.cgi?id=2562
--scott
___
es-discuss mailin
There are a number of differences between ES5-style methods and ES6
methods. This is unfortunate, but probably inevitable.
* ES5 methods typically use "argument is present", while ES6 methods
treat an undefined argument as the same as a missing argument. For
example, compare Array#reduce to Arra
In the ES6 world, you should probably set up a Map for your switch
statement; that would allow you to easily use non-string cases.
--scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Brendan Eich-3 wrote
> Allen Wirfs-Brock wrote:
>> Do you have any real world use cases in mind that are driving the desire
>> for
>> Array.from to preserve sparseness?
>
> Use-cases for sparse arrays + copying them would be really helpful.
It was more call for a consistency, as all other method
On Feb 21, 2014, at 12:08 PM, David Herman wrote:
> I think it should be Module.isModule.
I don't think we actually need something named Module, but that's a separate
conversation I have in the queue to have with you.
But food for thought: for module loader reflection purposes, it would be be
no, it's in Reflect
Dave
On Feb 21, 2014, at 12:13 PM, Domenic Denicola
wrote:
> Is Module a global now?
>
> From: es-discuss on behalf of David Herman
>
> Sent: Friday, February 21, 2014 15:08
> To: Allen Wirfs-Brock
> Cc: es-discuss
> Subject: Re:
Is Module a global now?
From: es-discuss on behalf of David Herman
Sent: Friday, February 21, 2014 15:08
To: Allen Wirfs-Brock
Cc: es-discuss
Subject: Re: Detecting a Module object
I think it should be Module.isModule.
Dave
On Feb 21, 2014, at 10:57 AM
I think it should be Module.isModule.
Dave
On Feb 21, 2014, at 10:57 AM, Allen Wirfs-Brock wrote:
> it's not going to be instanceof for various technical reasons.
>
> I suspect, we can have a isModule predicate function somewhere. Perhaps,
> Reflect.isModule or Reflect.Loader.isModule...
>
On Feb 21, 2014, at 11:49 AM, Brendan Eich wrote:
> Allen Wirfs-Brock wrote:
>>> 1. Array.from already produces sparse arrays from array-likes:
>>>
>>> Array.from({ 0: 1, 2: 2, length: 3 }); // [1,,2]
>>>
>>> So why it doesn't from sparse arrays?
>>
>> Perhaps, this is an inconsistency that sh
Allen Wirfs-Brock wrote:
1. Array.from already produces sparse arrays from array-likes:
Array.from({ 0: 1, 2: 2, length: 3 }); // [1,,2]
So why it doesn't from sparse arrays?
Perhaps, this is an inconsistency that should be corrected by changing
the spec. to produce [1,2,undefined] in the ab
it's not going to be instanceof for various technical reasons.
I suspect, we can have a isModule predicate function somewhere. Perhaps,
Reflect.isModule or Reflect.Loader.isModule...
Allen
On Feb 21, 2014, at 3:53 AM, Guy Bedford wrote:
> Being able to do `m instanceof Module` is certainly a
Also see https://bugs.ecmascript.org/show_bug.cgi?id=2416
On Feb 21, 2014, at 8:13 AM, medikoo wrote:
> Currently per spec Array.from doesn't produce perfect copies of sparse
> arrays:
>
> Array.from([1,,2]); // [1, undefined, 2]
>
> I know it's been discussed [1] but there's not much feedback
In practice, I find that everything converts nicely to a string when you
precede it with a ternary assignment.
I also find that when you do that, it's pretty trivial to control what
those strings are, which makes `hasOwnProperty` superfluous.
I haven't used a switch in JavaScript for quite a few
On Fri, Feb 21, 2014 at 7:55 AM, Nick Krempel wrote:
> Also only works when you're switching on something with a meaningful
> conversion to string.
>
On 20 Feb 2014, at 21:20, Eric Elliott wrote:
> Object literals are already a great alternative to switch in JS:
>
> var cases = {
> val1: fu
Don,
You don't misunderstand at all! You've totally got it now. It's awesome
that you are using modern application architecture as teaching material.
As to your question about why not make the API easier to use, my answer is:
one person's easy-to-use is another person's performance problem.
As l
Currently per spec Array.from doesn't produce perfect copies of sparse
arrays:
Array.from([1,,2]); // [1, undefined, 2]
I know it's been discussed [1] but there's not much feedback.
It doesn't seem right for a few reasons:
1. Array.from already produces sparse arrays from array-likes:
Array.fr
Also only works when you're switching on something with a meaningful
conversion to string.
On 21 February 2014 07:03, Mathias Bynens wrote:
> On 20 Feb 2014, at 21:20, Eric Elliott wrote:
>
> > Object literals are already a great alternative to switch in JS:
> >
> > var cases = {
> > val1:
Being able to do `m instanceof Module` is certainly a lot nicer here though.
Just to return to the consideration of modules as classes, I still don't
understand what the major issue is with having a module as a class without
any prototype methods.
On 21 February 2014 00:07, Guy Bedford wrote:
28 matches
Mail list logo
