Le 11/02/2013 00:53, Andrea Giammarchi a écrit :
We have transpilers for everything else, we need few better things
today and FirefoxOS knows it, as example ... I'd love to see
discussions about all Mozilla proposals for FirefoxOS and not always
some tedious syntax for classes discussion, you
Allen Wirfs-Brock wrote:
On Feb 10, 2013, at 3:40 AM, Herby Vojčík wrote:
But I still think it is simpler to specify .map returning array,
always. You know you get an Array, you don't have to worry about magic
of Set, Map etc., if you wish to have it in other kind of container,
use
Le 11/02/2013 00:53, Andrea Giammarchi a écrit :
involve as many developers as possible, rather than provide /already
decided internal decisions based in already decided internal
pools/ nobody ever heard about out there (public pools or it didn't
happen)
hmm... I had skipped that part
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,
more specific, I still have one precedent case:
I sent out a survey 2 weeks ago and received 381 responses, 256 for
return-this and 125 for return something else (undefined, the new length or
size, the value).
A survey not proposed here, a survey proposed as result after already made
decision.
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 Sun, Feb 10, 2013 at 6:53 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
snip
involve as many developers as possible, rather than provide *already
decided internal decisions based in already decided internal pools* nobody
ever heard about out there (public pools or it didn't
On Mon, Feb 11, 2013 at 1:04 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
more specific, I still have one precedent case:
I sent out a survey 2 weeks ago and received 381 responses, 256 for
return-this and 125 for return something else (undefined, the new length or
size, the
I'll change/fix/explain that if you think is respectful, I still never had
an answer about that survey (who committed, and who decided that was the
way to do the survey).
On Mon, Feb 11, 2013 at 10:06 AM, Rick Waldron waldron.r...@gmail.comwrote:
On Sun, Feb 10, 2013 at 6:53 PM, Andrea
On Feb 10, 2013, at 1:04 PM, Tab Atkins Jr. wrote:
From what I've seen in the examples in this topic so far, it looks
like Array#from takes a second optional argument, which is a function
that you map the iterable elements through first, before giving them
to the constructor. So, you would
Rick, I have already updated the post and YES, TC39 **should** consider
what the rest of the world would like to do or the way has always done
something and expecting to do otherwise the one that's not respecting will
result to be TC39.
So, here, summarized my thoughts, re-explained in that post:
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*
I wish you hadn't posted this, it implies something that's not true and
reads as incredibly disrespectful. All input, from all sources, is given
a fair consideration. It stands to reason that well articulated,
From my experience, this is not true.
You can of course argue on what definitions of a
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
On Mon, Feb 11, 2013 at 1:29 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
Rick, I have already updated the post and YES, TC39 **should** consider
what the rest of the world would like to do or the way has always done
something and expecting to do otherwise the one that's not
And you thought that was useful for you to make a decision but you are part
of TC39 that decided that surveys should not make decisions.
Rick, I am trying to understand how it works here, and why surveys are not
considered and, if considered, why cannot these be public.
I did not want to
I am over, I don't care about that specific survey indeed.
It was expected to have hard life here with these kind of thoughts ... just
consider this import stuff, node.js community, the fact devs here more than
once said: let's do this way and at the end it was done in another ...
let's just
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
-
Thank you for this explanation. This is very interesting! If you don't mind,
I have some questions/concerns I'd like to clear up. (In particular I want to
make sure I understand; I don't intend to argue for one side or the other ATM,
but this change may require me to refactor some old code
On Monday, February 11, 2013, Nathan Wall wrote:
Thank you for this explanation. This is very interesting! If you don't
mind, I have some questions/concerns I'd like to clear up. (In particular
I want to make sure I understand; I don't intend to argue for one side or
the other ATM, but
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
31 matches
Mail list logo
