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 argui
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 tran
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 t
> 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 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.
>
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 cal
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
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 se
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
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 depen
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 m
>> 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
th
On Jul 8, 2011, at 7:47 PM, Brendan Eich wrote:
>> An it is really worth the effort. How often does anybody set Date components
>> in a situation that is so time critical that this would matter. (any
>> shouldn't dates be immutable...oh well)
>
> SunSpider, cough.
Forgot to say that mutable D
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 incl
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 mutat
On Jul 8, 2011, at 6:21 PM, Brendan Eich wrote:
> Sometimes people try to make a new Array instance be the prototype of some
> other object:
>
> js> var o = Object.create([])
> js> o[2] = 0
> 0
> js> o.length
> 0
> js> o[1] = 1
> 1
> js> o[0] = 2
> 2
> js> o.toString()
> ""
> js> o.slice(0,1)
>
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 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 = ne
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 crea
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 woul
On Jul 8, 2011, at 5:16 PM, Brendan Eich wrote:
> 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 ri
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 w
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 fak
> 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,
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 fa
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 quot
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,
n
...@mozilla.org [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 o
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
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 a
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 f
31 matches
Mail list logo
