Well, I think I understand what you're getting at: there's a sense in
which generators don't add the ability to do something that's *absolutely
impossible* to express in ES5.
OTOH, generators make it possible to express something that otherwise --
in general -- requires a deep
On Jul 14, 2011, at 12:00 AM, Luke Hoban wrote:
I don't want to quibble about philosophical pedantry, but that's really all I
mean by my shyness about General Principles. They're strictly *harder* to
decide on than the problem at hand. It's too easy to lose focus and waste
time arguing
On Jul 11, 2011, at 10:38 PM, Luke Hoban wrote:
If so, it seems safe to consider generators as sugar for producing
objects whose visible behavior could have been built independently. And
interoperation appears to work cleanly in both directions using these
objects.
You're talking
My understanding of generators was naively that they are syntactic sugar for
defining an iterator.
Well, I think I understand what you're getting at: there's a sense in which
generators don't add the ability to do something that's *absolutely impossible*
to express in ES5.
OTOH, generators
On Jul 12, 2011, at 11:28 AM, David Herman wrote:
No pejorative overtones intended. We just don't yet have any decent
terminology for distinguishing the full ES.next front end from the
backwards-compatible one.
In the working draft of the specification I'm using extended code to mean the
On Jul 10, 2011, at 4:01 PM, Brendan Eich wrote:
On Jul 10, 2011, at 3:54 PM, Brendan Eich wrote:
On Jul 10, 2011, at 3:02 PM, David Herman wrote:
I'm not sure what Array.prototype methods would or wouldn't work on
instances of SubArray.
All of them. They are all generic.
We're
I agree wholeheartedly with these. In fact, I'd go further on (2), and
say Anything that can be done declaratively can also be done
imperatively, using ES5 syntax.
Like most principles, I think these are reasonable to keep in mind but
not absolute. In particular, I see no sensible
On Jul 11, 2011, at 10:00 PM, Luke Hoban wrote:
So I was wrong about iterators being the general interoperable runtime
mechanism, but next/send/throw/close objects appear to be fully iterable and
consumable in generators. Is that right?
That's right, there is no nominal type test.
If
If so, it seems safe to consider generators as sugar for producing objects
whose visible behavior could have been built independently. And
interoperation appears to work cleanly in both directions using these
objects.
You're talking about interoperation in the old script calls new generator
I'm not sure what Array.prototype methods would or wouldn't work on
instances of SubArray.
All of them. They are all generic.
We're speaking too broadly here. It depends on what we want to work how. For
example, .map can't magically know how to produce a SubArray as its result if
that's
On Jul 10, 2011, at 3:02 PM, David Herman wrote:
I'm not sure what Array.prototype methods would or wouldn't work on
instances of SubArray.
All of them. They are all generic.
We're speaking too broadly here. It depends on what we want to work how. For
example, .map can't magically
On Jul 10, 2011, at 3:54 PM, Brendan Eich wrote:
On Jul 10, 2011, at 3:02 PM, David Herman wrote:
I'm not sure what Array.prototype methods would or wouldn't work on
instances of SubArray.
All of them. They are all generic.
We're speaking too broadly here. It depends on what we want
On Jul 8, 2011, at 2:58 PM, Brendan Eich wrote on the thread using Private name
objects for declarative property definition. :
But whatever the class syntax, and the disposition of private in class and
even classes in ES.next, I agree we should expect private declarative and
expression
On Jul 8, 2011, at 3:49 PM, Allen Wirfs-Brock wrote:
On Jul 8, 2011, at 2:58 PM, Brendan Eich wrote on the thread using Private
name objects for declarative property definition. :
But whatever the class syntax, and the disposition of private in class and
even classes in ES.next, I agree
On Jul 8, 2011, at 3:59 PM, Brendan Eich wrote:
But the stronger reason for function* as mandator
mandatory of course (need new keyboard).
generator syntax introducer came when we considered yield* (yield from in
Python's PEP380): the utility of a zero-iterations basis case for a
[mailto:es-discuss-boun...@mozilla.org] On
Behalf Of Allen Wirfs-Brock
Sent: Friday, July 08, 2011 3:49 PM
To: es-discuss@mozilla.org
Subject: Design principles for extending ES object abstractions
[snip...]
I wanted to generalize this a bit. In designing classes and other new ES
abstractions
On Jul 8, 2011, at 4:05 PM, Luke Hoban wrote:
I agree wholeheartedly with these. In fact, I’d go further on (2), and say
“Anything that can be done declaratively can also be done imperatively, using
ES5 syntax”.
The problem here is that some new syntax cannot be faked with old syntax,
I agree wholeheartedly with these. In fact, I'd go further on (2), and
say Anything that can be done declaratively can also be done
imperatively, using ES5 syntax.
The problem here is that some new syntax cannot be faked with old syntax,
namely function calls, without quoting code in
On Jul 8, 2011, at 4:27 PM, Luke Hoban wrote:
I agree wholeheartedly with these. In fact, I’d go further on (2), and
say “Anything that can be done declaratively can also be done
imperatively, using ES5 syntax”.
The problem here is that some new syntax cannot be faked with old
On Jul 8, 2011, at 4:27 PM, Luke Hoban wrote:
I agree wholeheartedly with these. In fact, I’d go further on (2), and
say “Anything that can be done declaratively can also be done
imperatively, using ES5 syntax”.
The problem here is that some new syntax cannot be faked with old
On Jul 8, 2011, at 3:49 PM, Allen Wirfs-Brock wrote:
2) Anything that can be done declaratively can also be done imperatively.
What's the imperative API for | (which has the syntactic property that it
operators on newborns on the right, and cannot mutate the [[Prototype]] of an
object that
I think I still haven't fully grokked what | means on array literals, but
could it also be used to subclass Array? For example:
function SubArray() {
return SubArray.prototype | [];
}
SubArray.prototype = new Array;
I'm not sure what Array.prototype methods would or
On Jul 8, 2011, at 5:48 PM, Allen Wirfs-Brock wrote:
On Jul 8, 2011, at 5:16 PM, Brendan Eich wrote:
What's the imperative API for | (which has the syntactic property that it
operators on newborns on the right, and cannot mutate the [[Prototype]] of
an object that was already created and
On Jul 8, 2011, at 5:53 PM, David Herman wrote:
I think I still haven't fully grokked what | means on array literals, but
could it also be used to subclass Array? For example:
function SubArray() {
return SubArray.prototype | [];
}
SubArray.prototype = new Array;
On Jul 8, 2011, at 5:53 PM, David Herman wrote:
I think I still haven't fully grokked what | means on array literals, but
could it also be used to subclass Array? For example:
yes, it creates a new object that is an array instance ([[Class]]=='Array',
support the length constraints, etc.)
On Jul 8, 2011, at 6:03 PM, Brendan Eich wrote:
On Jul 8, 2011, at 5:48 PM, Allen Wirfs-Brock wrote:
On Jul 8, 2011, at 5:16 PM, Brendan Eich wrote:
What's the imperative API for | (which has the syntactic property that it
operators on newborns on the right, and cannot mutate the
On Jul 8, 2011, at 6:38 PM, Allen Wirfs-Brock wrote:
And likewise for Function.create and RegExp.create. Boolean, Number, String,
and Date get nothing :-P.
Actually in the | proposal I define it to work with boolean, number, and
string literals on the LHS. Sorta useless but I included
27 matches
Mail list logo
