On "I got 99 problems and JavaScript syntax ain't one"

Dean Landolt dean at deanlandolt.com
Wed Oct 5 09:22:48 PDT 2011


On Wed, Oct 5, 2011 at 10:18 AM, John J Barton
<johnjbarton at johnjbarton.com>wrote:

>
>
> On Tue, Oct 4, 2011 at 2:33 PM, Bob Nystrom <rnystrom at google.com> wrote:
>
>>
>>
>> On Tue, Oct 4, 2011 at 2:12 PM, John J Barton <
>> johnjbarton at johnjbarton.com> wrote:
>>
>>>
>>>
>>> On Tue, Oct 4, 2011 at 12:59 PM, Bob Nystrom <rnystrom at google.com>wrote:
>>>
>>>>
>>>> A constructor is different from a regular function. Instead of returning
>>>> the value that the body of the function returns, it returns a special
>>>> newly-created object.
>>>>
>>>
>>> Sorry, already you lost me ;-)  I guess you mean the operand of "new"? If
>>> so, then the different thing is the operator 'new'. It's "new" that makes
>>> the operand a constructor.
>>>
>>
>> It's the yield that makes a function a generator. One is visible at the
>> callsite (which means you can *forget* it at the callsite), the other is
>> visible at the definition.
>>
>>
>>>
>>>
>>>
>>>> Likewise, a generator is a special function that doesn't return what the
>>>> body returns.
>>>>
>>>
>>> But it does not look special. There is nothing similar to 'new' involved
>>> in the invocation of the generator.
>>>
>>
>> That's good because it means whether or not a function returns an iterable
>> object by using yield or through some other means is an implementation
>> detail of the function and doesn't bleed into every callsite. Let's say
>> generators *did* have a callsite difference. Now imagine:
>>
>> function countdown() {
>>   for (let i = 10; i >= 1; i--) yield i;
>> }
>>
>> let counter = generate countdown(); // <-- in callsite
>> for (let i of counter) alert(i);
>> alert('boom!');
>>
>> This magic generate keyword means the function is to be treated like a
>> generator. But then later it turns out that -- is really slow and you want
>> to change countdown to:
>>
>> function countdown() {
>>   return [10, 9, 8, 7, 6, 5, 4, 3, 2, 1];
>> }
>>
>> Well, you can't. You'd have to fix each callsite too. Your abstraction has
>> leaked. So I think generators do the right thing here. (And, conversely, I
>> kind of think constructors do the *wrong* thing.)
>>
>
> We can agree that |new| is a mess even if we don't agree on generators.
>
>
>>
>> and the state of the generator is hidden from the developer as far as I
>>> can tell.
>>>
>>
>> That's correct. That's often the cost of concision. By analogy: you can do
>> a lot of stuff using either an explicit stack data structure or recursion.
>> Using recursion is often more concise but then the state is hidden from you
>> in the callstack. Sometimes that's a good trade-off, sometimes it's not.
>>
>
> Thanks, that analogy helps confirm my opinion of generators. In my
> experience, the good trade-off is recursion on data structures and the
> not-good-trade-off is recursion for iteration.  So far the only examples
> I've seen for generators involve iteration.
>
>
>>
>>
>>> I think generators are an excellent example of a feature that is well
>>> prototyped (in FF JS 1.7+). I think the developer uptake is minimal, outside
>>> of the original advocates. I don't hear any clamor for other browsers to
>>> implement this feature.
>>>
>>
>> Browsers don't clamor, users do. If it was up to the browsers, they
>> wouldn't implement anything. Implementing is hard work!
>>
>
> I've heard no clamor at all. Really this is a niche feature, an aid for the
> rare case where conventional iterators are a poor match.
>


Generators are more than iteration optimizations -- they enable shallow
frame continuations, and open the doors to some really nice async
programming patterns (just the beginnings of which are demonstrated by Dave
Herman's task.js [1]).

Again, they're not fully implemented in any engine, so library support is
practically non-existent. How are users supposed to clamor for a feature
that can't demonstrate itself as advantageous? I've heard plenty of calls
for language-level async support -- generators enable this without the
well-documented hazards of the alternatives.

[1] https://github.com/dherman/taskjs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111005/ec3e95d9/attachment-0001.html>


More information about the es-discuss mailing list