Re: Code smell? Iterator prototype has iterator method that returns "this"

[Jordan Harband]

`new weirdFunction()` would `=== iter` because a constructor that returns
an object (`this`), returns that object when `new`ed - which is how
functions have worked since ES3 (or probably ES1).

On Tue, Jul 26, 2016 at 9:31 PM, Michael Theriot <
michael.lee.ther...@gmail.com> wrote:

> There are many things I still don't understand about iterators...
>
> ```js
> var iter = [].values();
> iter[Symbol.iterator]() === iter;
>
> var weirdFunction = iter[Symbol.iterator];
> weirdFunction.call(iter) === iter;
>
> var weirdInstance = new weirdFunction(); // what is this??
> ```
>
>
> On Mon, Jul 25, 2016 at 10:19 AM, John Lenz  wrote:
>
>> This seems ripe for misuse:  you don't want two "owners" for the same
>> iterator calling "next" and normally, without the Iterator interface
>> implementation, you would expect "iterator()" to always return an instance
>> of the iterator that the caller "owned".
>>
>> Can anyone provide any historical context on why this method was added to
>> the "iterator"?
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Code smell? Iterator prototype has iterator method that returns "this"

[Michael Theriot]

There are many things I still don't understand about iterators...

```js
var iter = [].values();
iter[Symbol.iterator]() === iter;

var weirdFunction = iter[Symbol.iterator];
weirdFunction.call(iter) === iter;

var weirdInstance = new weirdFunction(); // what is this??
```


On Mon, Jul 25, 2016 at 10:19 AM, John Lenz  wrote:

> This seems ripe for misuse:  you don't want two "owners" for the same
> iterator calling "next" and normally, without the Iterator interface
> implementation, you would expect "iterator()" to always return an instance
> of the iterator that the caller "owned".
>
> Can anyone provide any historical context on why this method was added to
> the "iterator"?
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Why are object initializer methods not usable as constructors?

[/#!/JoePea]

I feel like recent changes in the language (ES6+) introduce new features
that don't have the flexibility as the pre ES6 language that we're used to.

For example, [`super` is static and inflexible](
https://esdiscuss.org/topic/the-super-keyword-doesnt-work-as-it-should)
which is not inline with how `this` works.

Object initializer methods are also limited. Suppose I want to define an
object that contains various constructors. I would be inclined to use
object-initializer shortcuts:

```js
let classes = {
  Cat() {},
  Dog() {},
  Bird() {}
}
```

but this doesn't work:

```js
new classes.Dog() // Uncaught TypeError: classes.Dog is not a constructor
```

So, here's another failure of intuition (`super` being static was also not
intuitive). We can fix this by writing:

```js
function Cat() {}
function Dog() {}
function Bird() {}

let classes = {
  Cat,
  Dog,
  Bird
}
```

but that's not as convenient. What's the reason why we shouldn't be able to
do that? I feel like JavaScript is being restricted in undesirable ways. I
love JavaScript because it has always been so flexible, and I would expect
the new features to continue being flexible. That's what makes JavaScript
great.

*/#!/*JoePea
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Code smell? Iterator prototype has iterator method that returns "this"

[Andreas Rossberg]

The ES6 iterator/iterable story has been criticised more than once, by a
number of people. Too lazy to dig up all those threads, but if you search
es-discuss for iterable and iterator you will find it a reoccurring scheme.
AFAIK, this thread contained the first such discussion:
https://mail.mozilla.org/pipermail/es-discuss/2013-March/029004.html

The short story from my POV is: the notion of iterators vs. iterables in
ES6 makes no coherent sense, but many people want their implicit
conversions despite any smell, and this basically provides (a
user-definable) one from anything to an iterator.

On 26 July 2016 at 04:16, Allen Wirfs-Brock  wrote:

>
> > On Jul 25, 2016, at 4:38 PM, John Lenz  wrote:
> >
> > Yes, but at the cost of being able to reason / declare what kind of
> object is actually required.  But, I'm sure there is nothing that can be
> changed here.
>
> The kind of object that is required is one that implements the Iterable
> interface (i.e., has a Symbol.interable method that returns an object that
> implements the Iterator interface).  What is unclear about that?
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss