The idea that iterators return themselves from their @@iterator (__iter__)
hook has years of actual programmer mileage in Python. I take that experience
seriously, compared to arguments from purity that tax the common use-cases.
I’d be happy with either solution, but let’s compare:
AFAICT,
On Tue 11 Jun 2013 11:08, Axel Rauschmayer a...@rauschma.de writes:
The idea that iterators return themselves from their @@iterator
(__iter__) hook has years of actual programmer mileage in Python. I
take that experience seriously, compared to arguments from purity
that tax
On Tue, Jun 11, 2013 at 2:08 AM, Axel Rauschmayer a...@rauschma.de wrote:
On the other hand, turning every iterator into an iterable puts the burden
on people implementing iterators: they have to implement the iterable
interface.
That's... not really a burden. It's literally just adding an
I found this comparison with C# illuminating, trying to make sense of this
thread.
- It uses duck-typing for its `foreach` loops, allowing them to work with
anything that has a `GetEnumerator` method.
- All of its collections do have this, by virtue of inheriting from
`IEnumerable` or
On Tue, Jun 11, 2013 at 4:34 AM, Andy Wingo wi...@igalia.com wrote:
So, my proposal would be to make the for-of RHS expect an iterator, and
remove the concept of iterable. So there's no need to check for
anything; you just assume you have an iterator.
I don't find the cost of this change
On Tue, Jun 11, 2013 at 8:42 AM, Jason Orendorff
jason.orendo...@gmail.comwrote:
Please look at any Python codebase. The right-hand side of a for loop is
most often just an identifier or simple expression naming a collection. You
will see a few calls to enumerate(), .items(), and so on, but
On 6/11/2013 5:50 AM, Tab Atkins Jr. wrote:
On Tue, Jun 11, 2013 at 2:08 AM, Axel Rauschmayer a...@rauschma.de wrote:
On the other hand, turning every iterator into an iterable puts the burden
on people implementing iterators: they have to implement the iterable
interface.
That's... not really
I believe Iterator should be an interface and not a class so I could extend
Array or ArrayLike implementing Iterator, when/if necessary, in order to
have a for/of compatible class.
We don't have interfaces ... I know, we could have mixins though,
compatible with @@things too.
My 2 cents
On
On Jun 11, 2013, at 9:41 AM, Brandon Benvie wrote:
On 6/11/2013 5:50 AM, Tab Atkins Jr. wrote:
On Tue, Jun 11, 2013 at 2:08 AM, Axel Rauschmayer a...@rauschma.de wrote:
On the other hand, turning every iterator into an iterable puts the burden
on people implementing iterators: they have to
On Jun 11, 2013, at 10:22 AM, Andrea Giammarchi wrote:
I believe Iterator should be an interface and not a class so I could extend
Array or ArrayLike implementing Iterator, when/if necessary, in order to have
a for/of compatible class.
We don't have interfaces ... I know, we could have
so you are saying instanceof would be bad while 'nextable' (same 'thenable'
concept) is a better approach?
Ages ago, I was using PHP SPL a lot and found the interface approach very
simple and nice, it's more suitable for Proxy objects in JS though...
that's why I've talked about mixin, to drop
Great proposal, Norbert!
Another tool that uses JavaScript to identify identifiers as per ECMAScript 5.1
/ Unicode 6.2 is http://mothereff.in/js-variables.
For a list of bug reports regarding identifier handling in browsers /
JavaScript engines, see
On Jun 11, 2013, at 11:07 AM, Andrea Giammarchi wrote:
so you are saying instanceof would be bad while 'nextable' (same 'thenable'
concept) is a better approach?
of course
Ages ago, I was using PHP SPL a lot and found the interface approach very
simple and nice, it's more suitable for
Axel Rauschmayer wrote:
The idea that iterators return themselves from their @@iterator
(__iter__) hook has years of actual programmer mileage in Python. I
take that experience seriously, compared to arguments from purity
that tax the common use-cases.
I’d be happy with either solution, but
Andreas Rossberg wrote:
On 11 June 2013 14:50, Tab Atkins Jr.jackalm...@gmail.com wrote:
On Tue, Jun 11, 2013 at 2:08 AM, Axel Rauschmayera...@rauschma.de wrote:
And it becomes harder to distinguish the interfaces, should you
need to [1]. IMO, the purity argument also counts: this technique
I personally +1 that but most likely they'll come back saying there is no
time for that ... Object.mixin hasn't even been discussed in details ...
however, it's in current ES6 draft so once that is defined, maybe it will
be quick and easy to add mixin in the class? let's see
On Tue, Jun 11, 2013
Brian Di Palma wrote:
Sorry for the OT message.
On Tue, Jun 11, 2013 at 6:22 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
We don't have interfaces ... I know, we could have mixins though, compatible
with @@things too.
The concepts of Mixins has cropped up before in discussions
On Tue, Jun 11, 2013 at 5:33 PM, Brendan Eich bren...@mozilla.com wrote:
Brian Di Palma wrote:
Sorry for the OT message.
On Tue, Jun 11, 2013 at 6:22 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
We don't have interfaces ... I know, we could have mixins though,
compatible
if it's about being mature, then this is mature enough, if Object.mixin
will be finalized:
```javascript
class Bar extends [M1, M2, M3].reduce(
Object.mixin,
Object.create(Foo.prototype)
) {
// class definition ...
}
```
I must admit that looks weird though ...
br
On Tue, Jun 11, 2013
On Jun 11, 2013, at 8:07 PM, Andrea Giammarchi wrote:
if it's about being mature, then this is mature enough, if Object.mixin will
be finalized:
```javascript
class Bar extends [M1, M2, M3].reduce(
Object.mixin,
Object.create(Foo.prototype)
) {
// class definition ...
}
```
20 matches
Mail list logo
