Right, my bad then.
Juan
On Sat, Mar 12, 2011 at 8:37 PM, Brendan Eich wrote:
> On Mar 12, 2011, at 2:58 PM, Juan Ignacio Dopazo wrote:
>
> > Correct me if I'm wrong, but I think it should be like this:
> >
> > function S() {}
> >
> > function C() {
> > Object.defineProperty(this, 'constr
On 03/12/2011 12:02 AM, Brendan Eich wrote:
Take it from me, JS objects are not hashmaps and any would-be implementor who
tries that and tests on real code is quickly disabused of the notion. It's not
going to change, for named properties or any kind of property name.
This is true.
It is als
On Mar 12, 2011, at 11:27 AM, Charles Kendrick wrote:
> On Mar 12, 2011, at 10:41 AM, Brendan Eich wrote:
>
>> On Mar 12, 2011, at 9:54 AM, David Bruant wrote:
>>
>>> The little "issue" I see in returning 1) index properties in ascending
>>> order 2) all other properties in addition order is th
On Mar 12, 2011, at 2:58 PM, Juan Ignacio Dopazo wrote:
> Correct me if I'm wrong, but I think it should be like this:
>
> function S() {}
>
> function C() {
> Object.defineProperty(this, 'constructor', {
> value: C,
> enumerable: false,
> writable
Correct me if I'm wrong, but I think it should be like this:
function S() {}
function C() {
Object.defineProperty(this, 'constructor', {
value: C,
enumerable: false,
writable: false,
configurable: false
});
}
C.prototype = Object.create(S.prototype);
var o = new C();
console.log(o.constructor
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 view, it would require a bit of
re-writing for the
Hi,
The thread entitled "iteration order for Object" made me realize that
there is no defineProperties trap.
Let's imagine I'd like to implement an object which would keep track of
order in which own properties have been added/deleted to it. With the
defineProperty and delete traps I can already
Le 12/03/2011 21:24, Allen Wirfs-Brock a écrit :
> On Mar 12, 2011, at 11:58 AM, David Bruant wrote:
>
>> Le 12/03/2011 19:41, Brendan Eich a écrit :
>>> On Mar 12, 2011, at 9:54 AM, David Bruant wrote:
The little "issue" I see in returning 1) index properties in ascending
order 2) all ot
Le 12/03/2011 20:58, David Bruant a écrit :
> Le 12/03/2011 19:41, Brendan Eich a écrit :
>> On Mar 12, 2011, at 9:54 AM, David Bruant wrote:
>>> The little "issue" I see in returning 1) index properties in ascending
>>> order 2) all other properties in addition order is that there is a bit
>>> of
On Mar 12, 2011, at 11:58 AM, David Bruant wrote:
> Le 12/03/2011 19:41, Brendan Eich a écrit :
>> On Mar 12, 2011, at 9:54 AM, David Bruant wrote:
>>> The little "issue" I see in returning 1) index properties in ascending
>>> order 2) all other properties in addition order is that there is a bit
Le 12/03/2011 19:41, Brendan Eich a écrit :
> On Mar 12, 2011, at 9:54 AM, David Bruant wrote:
>> The little "issue" I see in returning 1) index properties in ascending
>> order 2) all other properties in addition order is that there is a bit
>> of information lost in the process: overall property
Bradley, the proposal is to define the iteration order for Object only, not all
objects (eg Array).
Also, if you were choosing between:
1. The strawman: preserve insertion order for non-index properties only, on
both Object and Array
2. My proposal: preserve insertion order for all properties
good point, the desugaring should be:
function c() {};
c.prototype=Object.create(s,protoype,{'constructor': { value:c, enumerable:
false, writable: false, configurable:false}});
We can debate about the attributes of the constructor (and the constructor's
prototype) property but my stake in the
On Mar 12, 2011, at 10:41 AM, Brendan Eich wrote:
> On Mar 12, 2011, at 9:54 AM, David Bruant wrote:
>
>> The little "issue" I see in returning 1) index properties in ascending
>> order 2) all other properties in addition order is that there is a bit
>> of information lost in the process: overal
On Sat, Mar 12, 2011 at 11:02 AM, Allen Wirfs-Brock
wrote:
[...]
> class c {
>
> }
> class c {
>
> }
> both are equivalent to:
> function c() {};
> c.prototype=Object.create(s.prototype);
[...]
So if "var b = new c", then "b.constructor" will be "s" instead of "c"?
_
I've added basic desugaring patterns to the class initialisers wiki page to
clarify things.
On Mar 12, 2011, at 9:44 AM, Juan Ignacio Dopazo wrote:
> (note correction in function c() {} example below. the Object.create is an
> essential part of the semantics)
>
> That makes complete sense! So
On Mar 12, 2011, at 10:41 AM, Brendan Eich wrote:
>>
>> What is the rational or use case behind having index properties at first
>> for objects and then the rest of properties?
>
> The "rationale" (such as it is) is that JS conflates lists and dicts in
> objects, but users mostly think about o
On Mar 12, 2011, at 9:54 AM, David Bruant wrote:
> The little "issue" I see in returning 1) index properties in ascending
> order 2) all other properties in addition order is that there is a bit
> of information lost in the process: overall property addition order
> (index properties included).
T
Le 12/03/2011 09:06, Brendan Eich a écrit :
> On Mar 11, 2011, at 12:49 PM, Charles Kendrick wrote:
>
>> Yes Allen, hence the urgency. If IE9 final ships that way, the
>> "goose is cooked":
>
> I hear tell of something happening next Monday. Goose, well-done,
> stuffed, I think.
>
>
>> 1. we will
>
> (note correction in function c() {} example below. the Object.create is an
> essential part of the semantics)
>
That makes complete sense! So the resulting prototype will be a new object.
Perfect!
Why were class bodies chosen as object initializers instead of function
> bodies?
>
> In ord
(note correction in function c() {} example below. the Object.create is an
essential part of the semantics)
On Mar 12, 2011, at 6:04 AM, Juan Ignacio Dopazo wrote:
> Hi! I hope you don't mind a couple of questions about this proposal.
>
> The meta property definition says:
>
> This causes th
On Mar 12, 2011, at 6:04 AM, Juan Ignacio Dopazo wrote:
> Hi! I hope you don't mind a couple of questions about this proposal.
>
> The meta property definition says:
>
> This causes the [[Prototype]] value of the new class’ prototype to be set to
> the prototype property value of the designat
Le 12/03/2011 11:29, Tom Schuster a écrit :
> Hi,
>
> the current definition of [[Construct]] doesn't allow to create
> non-constructable objects, but instead just invokes the call handler.
> On easy hackaround would be to check if the constructhandler has a
> [[Construct]] internal method. Then yo
Hi! I hope you don't mind a couple of questions about this proposal.
The meta property definition says:
This causes the [[Prototype]] value of the new class’ prototype to be set to
> the prototype property value of the designated constructor function
Shouldn't the superclass' prototype be chai
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Am 09.03.2011 19:48, schrieb P T Withington:
>
> Disagree. Since ECMAScript knows the type of the arguments, it does _not_
> need the format specifier to tell it the type (as C does).
Perhaps not for the data type - but for the representation of
Hi,
the current definition of [[Construct]] doesn't allow to create
non-constructable objects, but instead just invokes the call handler.
On easy hackaround would be to check if the constructhandler has a
[[Construct]] internal method. Then you could create non constructable
Functions like this:
Below are two partial implementations of LinkedHashMap in
JavaScript, with test code to populate with lots of keys and remove
half the keys at random, then alert() the results. Both implementations
add and maintain an index to provide O(1) lookups.
Each is compared to the speed of the equival
I believe it is very very important that the ECMAScript standard
specify that when a new Object is created, for..in iteration traverses
properties in the order they are added, regardless of whether the
properties are numeric or not.
Some users might prefer 'in the order of keys'. That is predict
On Mar 11, 2011, at 12:49 PM, Charles Kendrick wrote:
> Yes Allen, hence the urgency. If IE9 final ships that way, the "goose is
> cooked":
I hear tell of something happening next Monday. Goose, well-done, stuffed, I
think.
> 1. we will have a new de facto standard iteration order for Object
On Mar 11, 2011, at 12:11 PM, Charles Kendrick wrote:
> And again, I find your notion that an Object is "obviously" a HashMap very
> suspect.
John's simply mistaken :-).
Take it from me, JS objects are not hashmaps and any would-be implementor who
tries that and tests on real code is quickly d
30 matches
Mail list logo
