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
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 issues).
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 —
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
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
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 core
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, but the
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 heap
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, but the
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 via the heap
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
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 being
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 shorter
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 - a
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 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 7:55
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
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
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 my
19 matches
Mail list logo
