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
Also only works when you're switching on something with a meaningful
conversion to string.
On 21 February 2014 07:03, Mathias Bynens mathi...@opera.com wrote:
On 20 Feb 2014, at 21:20, Eric Elliott e...@ericleads.com wrote:
Object literals are already a great alternative to switch in JS:
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:
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
On Fri, Feb 21, 2014 at 7:55 AM, Nick Krempel ndkrem...@google.com 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 e...@ericleads.com wrote:
Object literals are already a great alternative to switch in
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
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.
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
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
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 should be corrected
I think it should be Module.isModule.
Dave
On Feb 21, 2014, at 10:57 AM, Allen Wirfs-Brock al...@wirfs-brock.com 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
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
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 methods are
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
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
On Fri, Feb 21, 2014 at 9:49 AM, Brendan Eich bren...@mozilla.com 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
___
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 al...@wirfs-brock.com wrote:
On Feb 21, 2014, at 12:08 PM, David Herman 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 new language optional arguments, undefined
is treated as not
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
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 new
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 (
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 to update
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
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
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
25 matches
Mail list logo
