Hi Claus,
On Wed 24 Jul 2013 22:07, Claus Reinke claus.rei...@talk21.com writes:
2 generators do not compose as freely as iteration functions,
because they are tied to special syntax and restricted contexts
You place blame on generators here, but beside the laments about deep
coroutines --
In 2008 I first proposed the addition of an integer division operator to
the language. At the time Brendan noted his regret for this oversight and
desire for the operator as well. I am not seeing this operator available in
the current draft. Can/will this be rectified?
a div b = (a - a % b) / b
2 generators do not compose as freely as iteration functions,
because they are tied to special syntax and restricted contexts
You place blame on generators here, but beside the laments about deep
coroutines -- totally understandable, but Brendan is right that that
they are pointless -- your
Claus Reinke wrote:
I have no idea why both you and Brendan assert that I was arguing/
rehashing for deep delimited continuations (let alone call/cc).
Because you wrote:
1 can be worked around, but not with the usual tools of function
definitions and calls - yield forces use of function*
Michael Haufe wrote:
In 2008 I first proposed the addition of an integer division operator
to the language. At the time Brendan noted his regret for this
oversight and desire for the operator as well. I am not seeing this
operator available in the current draft. Can/will this be rectified?
a
On Jul 25, 2013, at 12:11 PM, Waldemar Horwat walde...@google.com wrote:
On Thu, Jul 25, 2013 at 12:00 PM, Brendan Eich bren...@mozilla.com wrote:
Michael Haufe wrote:
In 2008 I first proposed the addition of an integer division operator to the
language. At the time Brendan noted his
Oliver Hunt wrote:
On Jul 25, 2013, at 12:11 PM, Waldemar Horwat walde...@google.com
mailto:walde...@google.com wrote:
On Thu, Jul 25, 2013 at 12:00 PM, Brendan Eichbren...@mozilla.com
mailto:bren...@mozilla.comwrote
Michael Haufe wrote:
In 2008 I first proposed the addition of
https://gist.github.com/arv/0bbb184710016e00d56c
The main goal of this proposal is to let us postpone the discussion
about private state until ES7, making sure that we solve the main use
cases.
--
erik
___
es-discuss mailing list
More of an aside: I think it would help if we had a list of what people
actually want from privacy.
I want:
1. Avoiding name clashes
2. Indicate that a property is not part of the public API of an object (along
with support from an IDE and a reflective API)
Other people seem to want:
3.
Axel Rauschmayer wrote:
More of an aside: I think it would help if we had a list of what
people actually want from privacy.
I want:
1. Avoiding name clashes
2. Indicate that a property is not part of the public API of an object
(along with support from an IDE and a reflective API)
Other
On 7/25/2013 1:31 PM, Erik Arvidsson wrote:
https://gist.github.com/arv/0bbb184710016e00d56c
The main goal of this proposal is to let us postpone the discussion
about private state until ES7, making sure that we solve the main use
cases.
Having those properties be enumerable is very
Le 25/07/2013 22:31, Erik Arvidsson a écrit :
https://gist.github.com/arv/0bbb184710016e00d56c
The main goal of this proposal is to let us postpone the discussion
about private state until ES7, making sure that we solve the main use
cases.
I'm not sure I understand how this proposal lets TC39
On 7/25/2013 1:31 PM, Erik Arvidsson wrote:
https://gist.github.com/arv/0bbb184710016e00d56c
The main goal of this proposal is to let us postpone the discussion
about private state until ES7, making sure that we solve the main use
cases.
Differences from Symbols:
* enumerable
* visible to
As long as the domain is consistent with (%) or potentially
http://wiki.ecmascript.org/doku.php?id=strawman:modulo_operator I'm
indifferent as my applications are within int32
On Thu, Jul 25, 2013 at 3:03 PM, Brendan Eich bren...@mozilla.com wrote:
[...]
Michael, were you looking for
It is not clear what private state will look like. The relationship work
Mark has done looks promising but it is not yet clear that we need both
private state and unique symbols.
The intent of this proposal was to open the door for alternatives, that can
be used in ES6 and then make sure we get
On 7/25/2013 5:31 PM, Erik Arvidsson wrote:
It is not clear what private state will look like. The relationship
work Mark has done looks promising but it is not yet clear that we
need both private state and unique symbols.
Right, what I'm saying is that unique Symbols and private state
On Jul 25, 2013 3:30 PM, Brandon Benvie bben...@mozilla.com wrote:
On 7/25/2013 1:31 PM, Erik Arvidsson wrote:
https://gist.github.com/arv/0bbb184710016e00d56c
The main goal of this proposal is to let us postpone the discussion
about private state until ES7, making sure that we solve the
I do not understand why (1) iterators are specified using a self-updating
API when a functional API would seem preferable, or why (2) generators
are linked to functions, when block-level generators would seem to be
sufficient and less complex. In some more detail:
1. Why do iterators have an
18 matches
Mail list logo
