On Nov 30, 2011, at 10:39 AM, Anton Yatsenko wrote:
> Comprehensions in sense of arrays [x*y for x of .. for y of ..] with array as
> a result is pretty clear, on the other hand — everything is expression in (),
> and my gut (hi Doug) told me any possible thing, but not an object. That's
> why
On 01.12.2011 11:47, Andrea Giammarchi wrote:
Let's say this is an attempt to bring some new, easy to implement,
method for the native Object.prototype
Specially about forEach, the most used Array.prototype method out
there, it's quite clear JS developers would like to have similar
method to it
Let's say this is an attempt to bring some new, easy to implement, method
for the native Object.prototype
Specially about forEach, the most used Array.prototype method out there,
it's quite clear JS developers would like to have similar method to iterate
over objects, as key:value pairs rather than
On Nov 30, 2011, at 10:25 PM, Anton Yatsenko wrote:
> In case I've missed point — sorry.
There are several points. How one gets the Globalization "module" is one, but
the bigger points at issue involve API parameterization, overhead, and style
issues.
/be
>
> Anton.
>
> On Dec 1, 2011, at
Let me propose, guys:
If time for specification draft + vendors basic implementation less than time
to implement fully module based API (get rid of globals at all), then another
global name is a solution.
As this topic strategic targeted (IMO) I think it makes sense to draft both
options — as
On Nov 30, 2011, at 9:52 PM, Luke Hoban wrote:
>> Speaking on behalf of real world web developers, the opposition to
>> "Globalization" is that it's unnecessarily long. This is a long standing
>> problem with APIs that are designed by people that don't have to use them
>> everyday.
>
> Agreed
On Nov 30, 2011, at 9:08 PM, Rick Waldron wrote:
> Speaking on behalf of real world web developers, the opposition to
> "Globalization" is that it's unnecessarily long. This is a long standing
> problem with APIs that are designed by people that don't have to use them
> everyday.
Yeah, but sho
> Speaking on behalf of real world web developers, the opposition to
> "Globalization" is that it's unnecessarily long. This is a long standing
> problem with APIs that are designed by people that don't have to use them
> everyday.
Agreed - a shorter name would be better - but the alternative
Speaking on behalf of real world web developers, the opposition to
"Globalization" is that it's unnecessarily long. This is a long standing
problem with APIs that are designed by people that don't have to use them
everyday.
___
es-discuss mailing list
On Nov 30, 2011, at 7:14 PM, Luke Hoban wrote:
>> And further, all new functionality would need to be loaded via a module?
>>>
> This is a strong "yes", without qualification so far in my view. We
> intend for built-in modules to be accessible to unversioned/pre-Harmony
> script
> And further, all new functionality would need to be loaded via a module?
>>
This is a strong "yes", without qualification so far in my view. We intend
for built-in modules to be accessible to unversioned/pre-Harmony script
via the heap (Object.system.load...).
>>
>> This is
On Nov 30, 2011, at 3:28 PM, Luke Hoban wrote:
And further, all new functionality would need to be loaded via a module?
>
>>> This is a strong "yes", without qualification so far in my view. We intend
>>> for built-in modules to be accessible to unversioned/pre-Harmony script via
>>> the h
>>> And further, all new functionality would need to be loaded via a module?
>> This is a strong "yes", without qualification so far in my view. We intend
>> for built-in modules to be accessible to unversioned/pre-Harmony script via
>> the heap (Object.system.load...).
This is true for ES6, bu
On Nov 30, 2011, at 12:44 PM, Nicholas C. Zakas wrote:
> On 11/30/2011 12:01 PM, Brendan Eich wrote:
>> On Nov 29, 2011, at 1:19 PM, Nicholas C. Zakas wrote:
>>
>>> The reason I started down this path is because the API, as currently
>>> designed, doesn't fit in with the rest of the JavaScript c
On 11/30/2011 12:01 PM, Brendan Eich wrote:
On Nov 29, 2011, at 1:19 PM, Nicholas C. Zakas wrote:
The reason I started down this path is because the API, as currently designed,
doesn't fit in with the rest of the JavaScript core language. Just to summarize
some of my earlier points:
1) No pa
On Nov 29, 2011, at 1:19 PM, Nicholas C. Zakas wrote:
> The reason I started down this path is because the API, as currently
> designed, doesn't fit in with the rest of the JavaScript core language. Just
> to summarize some of my earlier points:
>
> 1) No part of core JavaScript uses namespaces
I've went through discussion and pointed pages.
David, I'm pretty sure you know why I've ask this. Saw your YUIConf talk and
that 2 lines slide simply scared me :)
Comprehensions in sense of arrays [x*y for x of .. for y of ..] with array as a
result is pretty clear, on the other hand — everyth
Le 30/11/2011 06:56, Allen Wirfs-Brock a écrit :
> On Nov 30, 2011, at 10:24 AM, David Bruant wrote:
>> Le 29/11/2011 23:07, Allen Wirfs-Brock a écrit :
>>> ...
>>> Objects serve as one of our primary abstraction mechanisms (the other is
>>> functions and function closures have similar allocation
On Nov 30, 2011, at 7:14 AM, Anton V. Yacenko wrote:
> It's interesting to me why () syntax returns object, and why not {}.
I assume you're talking about generator expressions, which have the syntax of
array comprehensions but using parentheses as their outer delimiter. The idea
originally came
Hi guys.
I'm sorry to spam root thread, but I could not find topic regarding
comprehensions. Please point me (it that topic exist).
It's interesting to me why () syntax returns object, and why not {}.
Thanks.
Anton.
___
es-discuss mailing list
es-discu
20 matches
Mail list logo
