On Sun, Feb 10, 2013 at 4:05 PM, Oliver Hunt oli...@apple.com wrote:
It turns out (at least in Python) that while you rarely have to directly
implement the raw iterator protocol, you seriously almost *never* have to
directly consume it. So it was the right design decision, in Python at
least,
On Feb 10, 2013, at 10:40 PM, Domenic Denicola wrote:
From: Brendan Eich [mailto:bren...@mozilla.com]
Domenic Denicola wrote:
-Original Message-
From: Brendan Eich [mailto:bren...@mozilla.com]
Sent: Sunday, February 10, 2013 03:20
Changing from hasMore/getNext to
On Feb 11, 2013, at 8:54 AM, Jason Orendorff jason.orendo...@gmail.com wrote:
On Sun, Feb 10, 2013 at 4:05 PM, Oliver Hunt oli...@apple.com wrote:
It turns out (at least in Python) that while you rarely have to directly
implement the raw iterator protocol, you seriously almost *never*
From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf
of Oliver Hunt [oli...@apple.com]
For now I would say that we shouldn't expose the internal implementation
behaviour of yield (which is what being able to explicitly create or call a
generator produces). That
On Feb 11, 2013, at 10:35 AM, Domenic Denicola dome...@domenicdenicola.com
wrote:
From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on
behalf of Oliver Hunt [oli...@apple.com]
For now I would say that we shouldn't expose the internal implementation
behaviour of yield
Domenic Denicola wrote:
From: Brendan Eich [mailto:bren...@mozilla.com]
Domenic Denicola wrote:
-Original Message-
From: Brendan Eich [mailto:bren...@mozilla.com]
Sent: Sunday, February 10, 2013 03:20
Changing from hasMore/getNext to current/moveNext does not eliminate two
methods
Allen Wirfs-Brock wrote:
To me, Domenic appears correct on this point. The difference between a method (a
function valued property that is intended to be explicitly called) and a state property
(not explicitly called, might be implemented as either a accessor or data property) is the only
Oliver Hunt wrote:
Saving the cost of generator overhead by making all iteration
technically slower by depending on exceptions (correct semantics mean
even optimising out the throw is tricky for default iteration generators).
What is slower?
/be
Domenic Denicola wrote:
From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf
of Oliver Hunt [oli...@apple.com]
For now I would say that we shouldn't expose the internal implementation
behaviour of yield (which is what being able to explicitly create or call a
On Mon, Feb 11, 2013 at 12:30 PM, Oliver Hunt oli...@apple.com wrote:
Saving the cost of generator overhead by making all iteration
technically slower by depending on exceptions (correct semantics mean even
optimising out the throw is tricky for default iteration generators).
We are epicly
On Feb 11, 2013, at 1:29 PM, Brendan Eich bren...@mozilla.com wrote:
Domenic Denicola wrote:
From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on
behalf of Oliver Hunt [oli...@apple.com]
For now I would say that we shouldn't expose the internal implementation
On Feb 11, 2013, at 1:33 PM, Jason Orendorff jason.orendo...@gmail.com wrote:
On Mon, Feb 11, 2013 at 12:30 PM, Oliver Hunt oli...@apple.com wrote:
For now I would say that we shouldn't expose the internal implementation
behaviour of yield (which is what being able to explicitly create or
Oliver Hunt wrote:
On Feb 11, 2013, at 1:29 PM, Brendan Eichbren...@mozilla.com wrote:
Domenic Denicola wrote:
From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf
of Oliver Hunt [oli...@apple.com]
For now I would say that we shouldn't expose the internal
On Feb 11, 2013, at 1:58 PM, Brendan Eich bren...@mozilla.com wrote:
Oliver Hunt wrote:
So what you're saying is that people who attend in person meetings are able
to veto proposals,
No, I didn't say that. You are good at logic, I've seen your code. I know you
grok P - Q does not
Oliver Hunt wrote:
On Feb 11, 2013, at 1:58 PM, Brendan Eichbren...@mozilla.com wrote:
Oliver Hunt wrote:
So what you're saying is that people who attend in person meetings are able to
veto proposals,
No, I didn't say that. You are good at logic, I've seen your code. I know you grok P
-
Brendan Eich wrote:
More, the bigger point to make is that developers who do code implementors
iterators, of course.
don't have to write two methods, as Jason pointed out.
/be (fat fingers)
___
es-discuss mailing list
es-discuss@mozilla.org
This is like C#'s current / moveNext, which was discussed at the May
2011 TC39 meeting (see ), and then again last September. See
https://mail.mozilla.org/pipermail/es-discuss/2012-September/025241.html
Rehashed Java (hasMore/getNext) and C# (Current/MoveNext) protocols
involving two
-Original Message-
From: Brendan Eich [mailto:bren...@mozilla.com]
Sent: Sunday, February 10, 2013 03:20
Changing from hasMore/getNext to current/moveNext does not eliminate two
methods that can get out of sync. You can imagine one is a property, not a
method, but the general case
FWIW, there continue to be strong misgivings about the pythonesqe design we
have now, but Mozilla insists on the back of their shipping implementation.
Many feel that exceptions for control-flow are a missdesign, myself
included, but at this point the ship us nearly past the lighthouse on its
way
Le 10/02/2013 13:21, Alex Russell a écrit :
FWIW, there continue to be strong misgivings about the pythonesqe
design we have now, but Mozilla insists on the back of their shipping
implementation. Many feel that exceptions for control-flow are a
missdesign, myself included
I agree and also
Alex Russell wrote:
FWIW, there continue to be strong misgivings about the pythonesqe
design we have now,
See below for how strong.
but Mozilla insists on the back of their shipping implementation.
No, that's completely false. There's no meeting notes to back you. If
you objected all
Le 10/02/2013 16:21, David Bruant a écrit :
Le 10/02/2013 13:21, Alex Russell a écrit :
FWIW, there continue to be strong misgivings about the pythonesqe
design we have now, but Mozilla insists on the back of their shipping
implementation.
I have made a mistake in keeping that part of the
Le 10/02/2013 16:50, David Bruant a écrit :
Le 10/02/2013 16:21, David Bruant a écrit :
Many feel that exceptions for control-flow are a missdesign, myself
included
That's the only part I disagree with and my answer applied to.
s/disagree/agree...
Just a couple of questions on this wonderous topic:
* how is 'e instanceof StopIteration' intended to work across multiple global
objects?
* how firmly are we wedded to this? I can't imagine there is too much code that
currently depends on manually catching StopIteration given ES6 is not
I have continued my wanderings on that topic elsewhere. Sharing as food
for thought:
Le 10/02/2013 16:21, David Bruant a écrit :
idealworld
I initially thought that yield could be the sugar of endframe as
yield(value), but yield and return/throw are different. In the former
case, the frame
Le 10/02/2013 20:55, Oliver Hunt a écrit :
Just a couple of questions on this wonderous topic:
* how is 'e instanceof StopIteration' intended to work across multiple global
objects?
StopIteration has a special StopIteration [[Brand]] [1], so the
cross-global story shouldn't be a problem for
On Feb 10, 2013, at 1:01 PM, David Bruant bruan...@gmail.com wrote:
Le 10/02/2013 20:55, Oliver Hunt a écrit :
Just a couple of questions on this wonderous topic:
* how is 'e instanceof StopIteration' intended to work across multiple
global objects?
StopIteration has a special
On Sun, Feb 10, 2013 at 1:55 PM, Oliver Hunt oli...@apple.com wrote:
I do dislike the exception based termination, I _think_ i'd prefer next()
and hasNext() style iteration over exceptions, especially given that for
the most part these are hidden by clean syntax.
Yuck. Python's iterator
On Feb 10, 2013, at 1:55 PM, Jason Orendorff jason.orendo...@gmail.com wrote:
On Sun, Feb 10, 2013 at 1:55 PM, Oliver Hunt oli...@apple.com wrote:
I do dislike the exception based termination, I _think_ i'd prefer next() and
hasNext() style iteration over exceptions, especially given that
Le 10 févr. 2013 à 22:01, David Bruant bruan...@gmail.com a écrit :
snip
I have to note that there is a minor security hazard in code using iterators
naively:
import process from m;
var a = [1, 2, 3, 4, 5];
var next = 0;
var it = {
next: function(){
Has the iteration protocol been given a close look since unique symbols hit
the scene? I know the iterator key was changed to a symbol (which makes
great sense) but ISTM symbols offer up some design flexibility that, as far
as I know, just isn't possible in any of the other languages mentioned WRT
This is exactly what's proposed for ES6, except s/.source/.value/. See
also PEP-380.
/be
Claude Pache wrote:
In order to mitigate the problem, instead of throwing a generic StopIteration, I think we
ought to throw a specific StopIteration instance with information on which iterator has
Dean Landolt wrote:
Has the iteration protocol been given a close look since unique
symbols hit the scene?
Previously:
https://mail.mozilla.org/pipermail/es-discuss/2012-November/026647.html
/be
___
es-discuss mailing list
es-discuss@mozilla.org
Domenic Denicola wrote:
-Original Message-
From: Brendan Eich [mailto:bren...@mozilla.com]
Sent: Sunday, February 10, 2013 03:20
Changing from hasMore/getNext to current/moveNext does not eliminate two
methods that can get out of sync. You can imagine one is a property, not a
From: Brendan Eich [mailto:bren...@mozilla.com]
Domenic Denicola wrote:
-Original Message-
From: Brendan Eich [mailto:bren...@mozilla.com]
Sent: Sunday, February 10, 2013 03:20
Changing from hasMore/getNext to current/moveNext does not eliminate two
methods that can get
Le 11 févr. 2013 à 06:25, Brendan Eich bren...@mozilla.com a écrit :
This is exactly what's proposed for ES6, except s/.source/.value/. See also
PEP-380.
/be
By reading [1] (and PEP-380), it seems to me that the value property is
rather set to be the value of the return statement. Thus,
Claude Pache wrote:
Le 11 févr. 2013 à 06:25, Brendan Eichbren...@mozilla.com a écrit :
This is exactly what's proposed for ES6, except s/.source/.value/. See also
PEP-380.
/be
By reading [1] (and PEP-380), it seems to me that the value property is
rather set to be the value of the
Le 11 févr. 2013 à 03:44, Dean Landolt d...@deanlandolt.com a écrit :
Has the iteration protocol been given a close look since unique symbols hit
the scene? I know the iterator key was changed to a symbol (which makes great
sense) but ISTM symbols offer up some design flexibility that, as
38 matches
Mail list logo
