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
Thanks for the explanations and additional details. Let me first try
to rephrase, to see whether I've understood your reasoning:
The problem comes from the partial integration of types in ES,
specifically having typed arrays but no easy way to express and
control the types of the functions
Allen Wirfs-Brock wrote:
On Feb 9, 2013, at 3:01 PM, Herby Vojčík wrote:
Allen Wirfs-Brock wrote:
ethods.
The choice we agreed to, at the meeting is
1) Array.prototype.map produces the same kind of array that it
was applied to, so:
for the above example m instance of V will be true.
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...
I do not understand what is being proposed. When I try to imagine a
proposal starting from what has been said, I have not been able to imagine
something that works. But that's not a criticism. What is this alternate
privacy idea?
On Sat, Feb 9, 2013 at 11:07 PM, Brendan Eich bren...@mozilla.com
Le 10/02/2013 08:07, Brendan Eich a écrit :
Allen Wirfs-Brock wrote:
Note that the enumerable attribute really only affects for-in
enumeration (and Object.keys), neither of which enumerates symbols
anyway. That, means that the enumerable attribute really has has no
current meaning for symbol
Le 10/02/2013 17:16, Mark S. Miller a écrit :
I do not understand what is being proposed. When I try to imagine a
proposal starting from what has been said, I have not been able to
imagine something that works. But that's not a criticism. What is this
alternate privacy idea?
My understanding
How does this interact with Proxies[1]? I know the answer probably starts
with whitelist, but let's spell it out in this context, and test it
against the 8 membrane transparency cases previously discussed. If there
are good answers for all of these, and if we can reuse enumerable: for this
purpose
On Sun, Feb 10, 2013 at 4:33 AM, Claus Reinke claus.rei...@talk21.comwrote:
(snip)
How would use produce an Array of strings from an Int32Array?
Somewhat like
Array.from( int32Array ).map( (elem) = elem.toString() )
Implementations would be free to replace the syntactic pattern
On Feb 10, 2013, at 1:33 AM, Claus Reinke wrote:
Thanks for the explanations and additional details. Let me first try to
rephrase, to see whether I've understood your reasoning:
The problem comes from the partial integration of types in ES, specifically
having typed arrays but no easy
On Feb 10, 2013, at 3:40 AM, Herby Vojčík wrote:
Allen Wirfs-Brock wrote:
On Feb 9, 2013, at 3:01 PM, Herby Vojčík wrote:
...
I think the best would be (it is dead simple): - to _always_ use
Array in map result
In your previous post you said:
1. .map should work for Array
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 3:04 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Sun, Feb 10, 2013 at 11:18 AM, Rick Waldron waldron.r...@gmail.com
wrote:
(Assuming a future where the DOM's NodeList inherits from Array)
How would you produce a NodeList from an arbitrary array of strings?
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
David Bruant wrote:
* whether the symbol is reflected by Object.getOwnPropertyNames
That's already spec'ed in ES5 and it never returns non-string names, so
no symbol (name) proposal has ever extended it. At least as far as I know!
/be
___
Apologies if I am bothering here but, you know, where else put these topics
under your attention? :)
So, one is about trying to do not loose focus on what's already out there
and how is used
http://webreflection.blogspot.com/2013/02/jokes-part.html
tl;dr
For A Better JS Future
1. do not
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
34 matches
Mail list logo
