I know pretty well I’m probably not going to convince the believers here, but
this whole “we need an indication at the beginning of the function” thing is
kinda not making sense.
For starter, the generator function always starts at its first line. If what
you {Till Schneidereit} mean is that the execution can resumes at another line
when someome call .next() on the iterator, then we speak about something else,
which is absolutely no different than
function SomeIterator() {
function onFirstCalll(v) {
// continue execution
...
// next step in generator
resumeDoSomething = onSecondCall;
return someYieldedValue;
}
function onSecondCall(v) {
// continue execution
...
// next step in generator
resumeDoSomething = onExtraCall;
return someYieldedValue;
}
function onExtraCall() {
throw new Error(“The iterator cannot yield more values”)
}
// generator boilerplate
var resumeDoSomething = onFirstCalll;
return {
next: function next(v) {
return resumeDoSomething(v);
},
...
};
}
for which there’s no specific indication required. As noted before in the
discussion, most programming languages providing “yield” support do not require
anything specific to support it. Interestingly, VB.NET is not one of those, but
they deliberately choose some non-function syntax fwiw.
In all honesty, Async functions and Promise-returning functions can very often
be more challenging to grasp than iterators and there’s no “syntax flag” for
those things.
The best way to tell what your function does is to choose a name that makes
clear how its internal working behaves, and possibly some informational
return-type information (via a comment or Typescript-like preprocessors), not
by adding a distracting and non-self-descriptive star symbol next to the
function keyword.
Also, I totally dislike the fact I can’t use “yield” in a lambda function
because of this star thing. I can totally imagine a function taking an iterator
as argument, and being able to use a lambda function could totally make sense
to define the iterator. The star syntax is an arbitrary and not very useful
restriction, in my opinion.
De : Till Schneidereit
Envoyé : samedi 31 août 2013 18:05
À : Brendan Eich
Cc : es-discuss
On Sun, Sep 1, 2013 at 2:43 AM, Brendan Eich <[email protected]> wrote:
Lots of constructors/factories out there. An essential (see Aristotle) argument
for why function* for generator syntax (ignoring trumping reasons 1&2) must say
why *this* particular factory needs special (a la function*) head syntax.
For all non-generator functions, one important assumption for reading them
holds: they always start with the first instruction, and any (potential)
deviations from linear control flow are visible exactly where they (might)
happen. Not so for generators: to understand what invoking a generator might
do, you have to look at all the potential entry points, i.e., all instructions
following a yield in the control flow. If you want to do more localized
reasoning and are interested in a specific invocation, you also have to reason
about which might be the relevant one. Granted, that is essentially state and
any function's control flow can be state-dependent, so this point might be less
important.
Still, having to look at an unknown number of entry points to understand how
control flows through a piece of code seems like something you'll want to know
about. Without searching the code for "yield"._______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
