Yep, thanks Brendan,
I filed the bug https://bugzilla.mozilla.org/show_bug.cgi?id=641436
But the thing with `this` is still interesting for me. So in this particular
case `this` should be set to `undefined`. Should it be always set to
`undefined` (strict) / global object and regardless --
On Fri, 11 Mar 2011 16:48:04 +0100, Charles Kendrick
char...@isomorphic.com wrote:
Just connecting the dots - I addressed this in my first email on the
subject. While it superficially sounds like a good compromise, I
actually think it's the worst possibility: it requires browser vendors
On Mar 14, 2011, at 3:02 AM, Dmitry Soshnikov wrote:
Yep, thanks Brendan,
I filed the bug https://bugzilla.mozilla.org/show_bug.cgi?id=641436
But the thing with `this` is still interesting for me. So in this particular
case `this` should be set to `undefined`.
No, |this| is not set to
On Mar 14, 2011, at 5:09 AM, Lasse Reichstein wrote:
On Fri, 11 Mar 2011 16:48:04 +0100, Charles Kendrick char...@isomorphic.com
wrote:
Just connecting the dots - I addressed this in my first email on the
subject. While it superficially sounds like a good compromise, I actually
think
On Mar 13, 2011, at 2:16 PM, Brendan Eich wrote:
...
Allen, did you want 'constructor' to be in the class prototype?
Absolutely. Here is what the proposal says
The value a class initialiser is a new function object. It has a “prototype”
property whose value is also a new object. For
On Mon, Mar 14, 2011 at 10:21 AM, Brendan Eich bren...@mozilla.com wrote:
Web developers find and exploit many de-facto standards. Enumeration order
being insertion order for non-arrays at least, if not for all objects
(arrays tend to be populated in index order), is old as the hills and web
Aside from the JSON example of populating a dropdown list given (which I
will agree is a real if contrived use case), there has been a lot of talk
of thousands of web developers depending on preserving insertion order,
but not one concrete example -- do you have one?
Two examples I've seen
A spec workaround would be to stop converting numeric keys to
Strings, ie, 1 and '1' would be different keys. Then number keys
could behave as Array indices, while String keys would behave
as other properties.
Interesting idea, but I think it would be to big of a break from ES5,
ES in general
Le 14/03/2011 17:02, John Tamplin a écrit :
On Mon, Mar 14, 2011 at 10:21 AM, Brendan Eich bren...@mozilla.com
mailto:bren...@mozilla.com wrote:
Web developers find and exploit many de-facto standards.
Enumeration order being insertion order for non-arrays at least,
if not for
On Mar 13, 2011, at 2:10 PM, Faisal Vali wrote:
...
In the context of the proposals(*), are the following syntactic
constructs valid within object initialisers - and what are their
semantics?
1) var toString : const() { ... }
2) var toString : function() {... }
3) var toString : #()
I don't know about insertion order being important, but certainly it's
natural to want to express order with object literals (or equivalently,
JSON). If we can't rely on enumeration order matching key ordering in the
literal, then the programmer has to express that ordering twice: once
On 2011-03-13, at 18:15, Juan Ignacio Dopazo wrote:
@Brendan My mistake was thinking that setting enumerable to false also made
it return false on hasOwnProperty().
The idea behind it was to be able to walk down the prototype chain by doing
o.constructor.prototype.contructor.proto... But
On 14/03/2011, at 18:32, P T Withington wrote:
On 2011-03-13, at 18:15, Juan Ignacio Dopazo wrote:
The idea behind it was to be able to walk down the prototype chain by doing
o.constructor.prototype.contructor.proto... But then I realized that's not
the case even in today's javascript.
On 14.03.2011 16:51, Brendan Eich wrote:
On Mar 14, 2011, at 3:02 AM, Dmitry Soshnikov wrote:
Yep, thanks Brendan,
I filed the bug https://bugzilla.mozilla.org/show_bug.cgi?id=641436
But the thing with `this` is still interesting for me. So in this particular
case `this` should be set to
On 11:59 AM, P T Withington wrote:
ES3 does not have the luxury of Object.create,
Object.create is easily implemented with the ES3 language.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
I guess something along the lines of
new ((function () { return this; }).prototype = String);
How would you do Object.create(null) ?
On Mon, Mar 14, 2011 at 8:17 PM, Douglas Crockford
doug...@crockford.com wrote:
On 11:59 AM, P T Withington wrote:
ES3 does not have the luxury of
Le 12/03/2011 23:45, David Bruant a écrit :
Hi,
I think it would be worth for spec readability to give a name to the
for-in property enumeration internal method and list it as such in ES5
8.6.2 Table 8 regardless the fact that it is implementation-dependent.
From the spec edition point of
I.e. again, what I notice (and asked), is that there's no any info in the
draft spec about `this` value of the generator's context. I think it would be
good to add this information.
A generator function is still a function, and |this| binding is orthogonal to
yield making the surrounding
On Mar 14, 2011, at 11:02 AM, John Tamplin wrote:
On Mon, Mar 14, 2011 at 10:21 AM, Brendan Eich bren...@mozilla.com wrote:
Web developers find and exploit many de-facto standards. Enumeration order
being insertion order for non-arrays at least, if not for all objects (arrays
tend to be
Hi David,
We have a strawman for making the enumeration order well-specified:
http://wiki.ecmascript.org/doku.php?id=strawman:enumeration
Would that not be sufficient for the defineProperties case? I'd prefer that to
adding another trap.
Dave
On Mar 12, 2011, at 1:15 PM, David Bruant
On 14.03.2011 23:02, Brendan Eich wrote:
I.e. again, what I notice (and asked), is that there's no any info in the draft
spec about `this` value of the generator's context. I think it would be good to
add this information.
A generator function is still a function, and |this| binding is
On 3/12/2011 2:08 AM, Claus Reinke wrote:
I notice that you don't count initialization for the native Object
variant. Apart from fixing that,
This is not a flaw. The initialization phase for the orderedMap creates an index. This is not
needed for Object because the Object *is* the index.
On 14/03/2011, at 21:34, P T Withington wrote:
On 2011-03-14, at 14:29, Jorge wrote:
Isn't that the purpose of Object.getPrototypeOf() ?
If I have a class `c` whose superclass is `s`, I'm trying to understand how I
can get from an object that is an instance of `c` to the superclass. I
On 3/13/2011 2:07 PM, Brendan Eich wrote:
On Mar 13, 2011, at 3:58 PM, Charles Kendrick wrote:
Brendan, Bradley and others - there's no need to search for a relatively
uncommon use case for ordered maps indexed by keys - a far more common use case
is enumerated data stored numerically, eg,
Hi,
I've been thinking about Function proxy use cases lately. Things that
the spec do and that could be convenient to emulate as well or just
things that could be useful.
* [[Construct]]-less functions.
All Array.prototype methods are like that as well as all global object
methods (parseInt...)
On Mar 14, 2011, at 9:42 AM, David Bruant wrote:
Le 14/03/2011 17:02, John Tamplin a écrit :
On Mon, Mar 14, 2011 at 10:21 AM, Brendan Eich bren...@mozilla.com wrote:
Web developers find and exploit many de-facto standards. Enumeration order
being insertion order for non-arrays at least,
On Mar 14, 2011, at 11:50 PM, John J. Barton wrote:
On 11:59 AM, Brendan Eich wrote:
However, there's no way for a generator function to return that instance,
because a generator function always implicitly returns a fresh generator
iterator when invoked. It could store |this| in the heap,
27 matches
Mail list logo
