+1 and I've raised same concerns 2 years ago [1]
IIRC the outcome was that VM should be good enough to handle objects with
very short lifecycle, I'm still convinced (behind tests) that generators
are overkill for IoT devices (low clock and way lower RAM).
Having always same object per iteration
I'm certainly in favor of VMs improving to handle that, and adding
pressure for it is good. However, optimizing a TypedArray temporary
arg to .set() is a much simpler problem than doing the escape analysis
necessary to be certain a .next() result doesn't escape from a calling
scope and isn't used
As specified, iterator .next() seems to be required to return a new
object instance for each iteration.
In my testing (and in my theory, as an absolute) this is a real
performance defect in the spec and it will make iterators inferior to
all other forms of sequence iteration, to the extent that
That case we can simply allow TemplateLiteral in Arguments. It will become
more consistent as well and causes less cognitive burden. We don't even
need to define MemberExpressionTemplateLiteral and CallExpression
TemplateLiteral any more. BTW, the only places where Arguments is referred
to are
In my testing (and in my theory, as an absolute) this is a real
performance defect in the spec and it will make iterators inferior to
all other forms of sequence iteration, to the extent that they may end
up being used very rarely, and developers will be biased away from Map
and Set as a result.
Replies inline
On 15 February 2015 at 06:16, Benjamin (Inglor) Gruenbaum
ing...@gmail.com wrote:
In my testing (and in my theory, as an absolute) this is a real
performance defect in the spec and it will make iterators inferior to
all other forms of sequence iteration, to the extent that they
So there's no point in going in circles here, I just want to address
the statement:
Even if we allow this 'optimization' it will take the engines as much
time to implement it so there is no gain from this anyway.
My premise is that this is a rather obvious bottleneck and it applies
to new APIs
On Sun, Feb 15, 2015 at 3:06 PM, Katelyn Gadd k...@luminance.org wrote:
In my testing Map and Set are outperformed by a trivial Object or
Array based data structure in every case, *despite the fact* that
using an Object as a Map requires the use of Object.keys() to be able
to sequentially
On Sun, Feb 15, 2015 at 7:16 AM, Benjamin (Inglor) Gruenbaum
ing...@gmail.com wrote:
This is something that can be solved at the VM level. VMs perform much
much smarter optimizations than this already. There is no reason to
sacrifice code correctness and the principle of least astonishment
This is actually exactly the kind of slow code Katelyn was talking about.
Also, you probably meant `set[Symbol.iterator]()` and `for... of`.
What Katelyn is talking about is optimizing .next in the example code to
not return a new object but to return the same one every time with
different values
When I can get more sound abstractions for no additional cost (eventually)
I'd rather not introduce implicit mutable state into the application.
Developers won't be aware of it being mutating and the whole notion of a
mutating-at-a-later-point return value is very error-prone in my opinion.
Again, where does this mutation occur? The spec shouldn't allow any such
thing to begin with; it should mandate exactly what my compiler does: as
soon as .next returns, copy .value into the loop variable. The developer
shouldn't have any access to the return value from within the loop at all;
if
Joe, I don't think we're having the same discussion.
Again, this is about the issue Katelyn raised about the return value of
`.next`.
Katelyn suggested that the return value of a `.next` call in the iteration
protocol - an object of the form `{value: value, done: boolean}` should be
allowed to
On Sun, Feb 15, 2015 at 7:43 AM, Benjamin (Inglor) Gruenbaum
ing...@gmail.com wrote:
This is actually exactly the kind of slow code Katelyn was talking about.
Also, you probably meant `set[Symbol.iterator]()` and `for... of`.
You are correct. I haven't switched to the 'of' syntax yet (need
Sorry about that, I think I'm unconsciously substituting return value of
.next for .next.value. I am talking about reusing the return object,
yes; for some reason in my head, return object of .next refers to
.next(), while return value of .next refers to .next().value.
Communication error on my
Making it a dynamic error at class definition time to extend null would
work but the motivation for not doing that was that someone might want to
create a class that has a {__proto__: null} prototype. Personally, I would
be fine with saying that this case is so rare that it would be better to
have
Interesting. I have never seen this pattern and don’t see what it could be
good for. Thus, a dynamic error at class definition time sounds good to me.
The purpose would be defining a class whose instances don't have
Object.prototype on their prototype chain. If extends null doesn't work,
On Sun, Feb 15, 2015 at 11:01 AM, Kevin Smith zenpars...@gmail.com wrote:
Interesting. I have never seen this pattern and don’t see what it could
be good for. Thus, a dynamic error at class definition time sounds good to
me.
The purpose would be defining a class whose instances don't have
Rather than making extends null alone a runtime error at class evaluation
time, is there a reason not to instead, make only a reference to super in
the constructor of a class that extends null be a runtime error at class
evaluation time?
On Sun, Feb 15, 2015 at 11:12 AM, Mark S. Miller
Making it a dynamic error at class definition time to extend null would work
but the motivation for not doing that was that someone might want to create a
class that has a {__proto__: null} prototype. Personally, I would be fine
with saying that this case is so rare that it would be better
The difference is the uncommon delimiter of the argument lists. If the
template literal must be surrounded by a pair of parentheses it will become
more visually significant. Since it's not, I think not allowing the line
terminator is reasonable.
On Sat, Feb 14, 2015 at 1:41 PM, Shinji Ikari
Kevin Smith wrote:
Have you tried writing a combinator which does exactly that? Take a
look at zip in python.
Right -- we don't add new syntax lightly, we'd need to see zip used a
lot, and at some irreducible-without-special-form overhead.
/be
The purpose would be defining a class whose instances don't have
Object.prototype on their prototype chain. If extends null doesn't work,
then I think you'd have to do something like this to achieve the same?
function NullBase() {}
NullBase.prototype = Object.create(null);
class
23 matches
Mail list logo
