ES4 draft: Object

classic Classic list List threaded Threaded
100 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

ES4 draft: Object

Lars Hansen-3
This is the draft for the Object class.  It's very similar to the Object
object in ES3, the only addition (to my knowledge) is the extra
parameter to propertyIsEnumerable.  And of course the specification
formalism is new.

Please comment.

--lars

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss

Object.html (20K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ES4 draft: Object

Erik Arvidsson
We (Google) find setting the [[DontEnum]] flag with
propertyIsEnumerable(name, flag) to be quite ugly.  I can't find any
references to why the setter was tagged along onto the getter in this
way?  Is there a reason why we don't want
setPropertyIsEnumerable(name, flag) instead of overloading the getter?

2008/3/5 Lars Hansen <[hidden email]>:

> This is the draft for the Object class.  It's very similar to the Object
>  object in ES3, the only addition (to my knowledge) is the extra
>  parameter to propertyIsEnumerable.  And of course the specification
>  formalism is new.
>
>  Please comment.
>
>  --lars
>
> _______________________________________________
>  Es4-discuss mailing list
>  [hidden email]
>  https://mail.mozilla.org/listinfo/es4-discuss
>
>



--
erik
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES4 draft: Object

Brendan Eich-2
On Mar 5, 2008, at 5:04 PM, Erik Arvidsson wrote:

> We (Google) find setting the [[DontEnum]] flag with
> propertyIsEnumerable(name, flag) to be quite ugly.  I can't find any
> references to why the setter was tagged along onto the getter in this
> way?  Is there a reason why we don't want
> setPropertyIsEnumerable(name, flag) instead of overloading the getter?

Adding any properties to Object.prototype at this point is difficult.  
You may break object-detection tests. Is it worth the risk?

/be

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

RE: ES4 draft: Object

Lars Hansen-3
In reply to this post by Erik Arvidsson
> -----Original Message-----
> From: Erik Arvidsson [mailto:[hidden email]]
> Sent: 5. mars 2008 17:04
> To: Lars Hansen
> Cc: [hidden email]
> Subject: Re: ES4 draft: Object
>
> We (Google) find setting the [[DontEnum]] flag with
> propertyIsEnumerable(name, flag) to be quite ugly.

Can't argue with that.

> I can't
> find any references to why the setter was tagged along onto
> the getter in this way?  Is there a reason why we don't want
> setPropertyIsEnumerable(name, flag) instead of overloading the getter?

It was felt, and I think it is still felt, that it is dangerous
to introduce new names on the Object prototype, because the
risk of clashes with code on the web is too great.  As the problem
that is solved by the overloading is really worth solving, the
ugliness of the solution seemed to be acceptable.

--lars

>
> 2008/3/5 Lars Hansen <[hidden email]>:
> > This is the draft for the Object class.  It's very similar to the
> > Object  object in ES3, the only addition (to my knowledge) is the
> > extra  parameter to propertyIsEnumerable.  And of course the
> > specification  formalism is new.
> >
> >  Please comment.
> >
> >  --lars
> >
> > _______________________________________________
> >  Es4-discuss mailing list
> >  [hidden email]
> >  https://mail.mozilla.org/listinfo/es4-discuss
> >
> >
>
>
>
> --
> erik
>
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES4 draft: Object

Erik Arvidsson
In reply to this post by Brendan Eich-2
I'm not sure it is such a big issue since the new method would be
[[DontEnum]] but I'm willing to let this rest.

The reason why I don't think it is that a big risk is that a lot of
people still use Array instead of Object for "associative arrays" and
I don't think adding the array extras introduced any problems.
Brendan, did you get any bug reports on Spidermonkey when array extras
was added?

On Wed, Mar 5, 2008 at 17:19, Brendan Eich <[hidden email]> wrote:

> On Mar 5, 2008, at 5:04 PM, Erik Arvidsson wrote:
>
>  > We (Google) find setting the [[DontEnum]] flag with
>  > propertyIsEnumerable(name, flag) to be quite ugly.  I can't find any
>  > references to why the setter was tagged along onto the getter in this
>  > way?  Is there a reason why we don't want
>  > setPropertyIsEnumerable(name, flag) instead of overloading the getter?
>
>  Adding any properties to Object.prototype at this point is difficult.
>  You may break object-detection tests. Is it worth the risk?
>
>  /be
>
>



--
erik
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES4 draft: Object

Brendan Eich-2
On Mar 5, 2008, at 5:28 PM, Erik Arvidsson wrote:

> I'm not sure it is such a big issue since the new method would be
> [[DontEnum]] but I'm willing to let this rest.

Object detection does not care about enumerability.

> The reason why I don't think it is that a big risk is that a lot of
> people still use Array instead of Object for "associative arrays" and
> I don't think adding the array extras introduced any problems.

Arrays are bad for "associative arrays" for many reasons, but  
probably their abusers don't care!

> Brendan, did you get any bug reports on Spidermonkey when array extras
> was added?

No, but consider that in our DOM at least, the global object,  
document, etc. etc. all delegate to Object.prototype -- not to  
Array.prototype.

/be

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES4 draft: Object

Brendan Eich-2
Hixie argued strongly on IRC today for something that does not  
overload set with get -- this seems to be the heart of the "ugly"  
objection, although there are other things to dislike about both the  
form and function of propertyIsEnumerable (it does not consider  
prototypes, as for-in does; its name is overlong and it violates  
standard naming conventions for "is" method).

To avoid injecting a public name into Object.prototype, we could put  
a new "setPropertyIsEnumerable" (yechh) name in the __ES4__  
namespace. Then there's no breaking change. We do this already, of  
course, but not for property attribute fiddling.

An alternative we've discussed, which Ian also brought up: add a  
keyword for declaring DontEnum properties. It turns out the full  
combination of property attributes is not interesting. We have const  
for DontDelete+ReadOnly (ReadOnly without DontDelete guarantees  
nothing, is worthless) including in object initialisers:

obj = {const PI: 22/7}; // Ohio legislature once so legislated

We have (I hope it got filed) a ticket asking for DontDelete by  
itself via var in object initialisers:

obj = {var x: "mutate me, but you can't delete me!"}

DontEnum is orthogonal but clear by default for binding and assigning  
forms in ES3. It is set for "built-ins", generally speaking (some odd  
exceptions that I recall in the Error objects -- I was not around  
much for ES3, although I did the work in Netscape 4 that fed into it!).

So, rather than add an ugly "dontenum" keyword that would be seldom  
used, the group preferred a built-in method. But this may have been a  
minor mistake. For those interested, here's the full rationale as I  
remember it:

Besides avoiding adding anything with a plain name to  
Object.prototype, the appeal (if you can call it that) of extending  
propertyIsEnumerable with an optional second argument lies in the  
ability to call it with two arguments in an ES3 implementation. That  
won't have any effect, but it won't break callin code in ES3  
implementations either.

Thus Ajax libraries such as Prototype (if it still does this) could  
add calls to turn off enumerability of properties the library sets on  
standard prototypes, and then those properties would disappear from  
for-in loop enumerations in ES4 implementations.

Mainly we do not expect the ability to turn off enumeration of a  
given property to be a frequent programmer task, so we did not want  
to add a new method if we could piggy-back on an existing  
Object.prototype method. For library authors, we wanted something  
that failed soft in ES3. And yeah, we knew it was "ugly", but  
propertyIsEnumerable is already ugly already.

/be
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

RE: ES4 draft: Object

Lars Hansen-3
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Brendan Eich
> Sent: 5. mars 2008 19:19
> To: Erik Arvidsson
> Cc: [hidden email] es4-discuss
> Subject: Re: ES4 draft: Object
>
> To avoid injecting a public name into Object.prototype, we
> could put a new "setPropertyIsEnumerable" (yechh) name in the
> __ES4__ namespace. Then there's no breaking change. We do
> this already, of course, but not for property attribute fiddling.

Right, it comes up from time to time.  Using __ES4__ here would set
a precedent that might not be the best.

> An alternative we've discussed, which Ian also brought up:
> add a keyword for declaring DontEnum properties. It turns out
> the full combination of property attributes is not
> interesting. We have const for DontDelete+ReadOnly (ReadOnly
> without DontDelete guarantees nothing, is worthless)
> including in object initialisers:
>
> obj = {const PI: 22/7}; // Ohio legislature once so legislated
>
> We have (I hope it got filed) a ticket asking for DontDelete
> by itself via var in object initialisers:
>
> obj = {var x: "mutate me, but you can't delete me!"}

Not filed in the Trac to my knowledge, but not forgotten.

> DontEnum is orthogonal but clear by default for binding and
> assigning forms in ES3. It is set for "built-ins", generally
> speaking (some odd exceptions that I recall in the Error
> objects -- I was not around much for ES3, although I did the
> work in Netscape 4 that fed into it!).

The text of E262-3 does not reveal anything unusual about the
Error objects, as far as I can see.

> So, rather than add an ugly "dontenum" keyword that would be
> seldom used, the group preferred a built-in method. But this
> may have been a minor mistake. For those interested, here's
> the full rationale as I remember it:
>
> Besides avoiding adding anything with a plain name to
> Object.prototype, the appeal (if you can call it that) of
> extending propertyIsEnumerable with an optional second
> argument lies in the ability to call it with two arguments in
> an ES3 implementation. That won't have any effect, but it
> won't break callin code in ES3 implementations either.
>
> Thus Ajax libraries such as Prototype (if it still does this)
> could add calls to turn off enumerability of properties the
> library sets on standard prototypes, and then those
> properties would disappear from for-in loop enumerations in
> ES4 implementations.
>
> Mainly we do not expect the ability to turn off enumeration
> of a given property to be a frequent programmer task, so we
> did not want to add a new method if we could piggy-back on an
> existing Object.prototype method. For library authors, we
> wanted something that failed soft in ES3. And yeah, we knew
> it was "ugly", but propertyIsEnumerable is already ugly already.

Also, a declarative form is of uncertain value, since the object
that receives the new property whose attr must be set, already
exists.  Thus if there is some sort of new keyword form it needs
to be associated with the assignment somehow.

--lars
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES4 draft: Object

Garrett Smith
In reply to this post by Brendan Eich-2
On Wed, Mar 5, 2008 at 7:19 PM, Brendan Eich <[hidden email]> wrote:
> Hixie argued strongly on IRC today for something that does not

>  So, rather than add an ugly "dontenum" keyword that would be seldom
>  used, the group preferred a built-in method. But this may have been a
>  minor mistake. For those interested, here's the full rationale as I
>  remember it:
>

obj = {dontenum length: 10} );

vs.

obj = {length: 10};
obj.propertyIsEnumerable("length", false);

Which is more ugly?

Garrett

>
>  /be
>  _______________________________________________
>  Es4-discuss mailing list
>  [hidden email]
>  https://mail.mozilla.org/listinfo/es4-discuss
>
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES4 draft: Object

Brendan Eich-2
In reply to this post by Lars Hansen-3
On Mar 6, 2008, at 5:30 PM, Lars Hansen wrote:

> The text of E262-3 does not reveal anything unusual about the
> Error objects, as far as I can see.


How embarrassing. The original implementation of Error and friends in  
SpiderMonkey, but one of the Netscape folks involved with ES3 in TG1  
at the time, makes Error.prototype.name and Error.prototype.message  
enumerable. Filed as this bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=421433

>
/be
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES4 draft: Object

Brendan Eich-2
In reply to this post by Garrett Smith
On Mar 6, 2008, at 5:57 PM, Garrett Smith wrote:

> On Wed, Mar 5, 2008 at 7:19 PM, Brendan Eich <[hidden email]>  
> wrote:
>> Hixie argued strongly on IRC today for something that does not
>
>>  So, rather than add an ugly "dontenum" keyword that would be seldom
>>  used, the group preferred a built-in method. But this may have  
>> been a
>>  minor mistake. For those interested, here's the full rationale as I
>>  remember it:
>>
>
> obj = {dontenum length: 10} );
>
> vs.
>
> obj = {length: 10};
> obj.propertyIsEnumerable("length", false);
>
> Which is more ugly?

Except the known use-case, setting DontEnum properties on standard  
prototypes (as the Prototype Ajax library did and still does AFAIK),  
does not use object initialisers.

Even so, "dontenum" as a compound word starting with a contraction  
whose apostrophe is elided is no beauty contest winner. But before  
arguing over those aesthetics, we need a more compelling use-case.

Remember that fixtures declared in classes are not enumerable, which  
is the right default for all the "native" (built-in is better, since  
these can be and are increasingly self-hosted) objects' properties.

/be

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

RE: ES4 draft: Object

Lars Hansen-3
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Brendan Eich
> Sent: 6. mars 2008 18:04
> To: Garrett Smith
> Cc: [hidden email] es4-discuss; Erik Arvidsson
> Subject: Re: ES4 draft: Object
>
>
> Remember that fixtures declared in classes are not enumerable, which  
> is the right default for all the "native" (built-in is better, since  
> these can be and are increasingly self-hosted) objects' properties.

Agreed "native" is misnomer now.  I've adopted "predefined" (or
"pre-defined" depending on my mood) instead of "built-in" but this is
something that will be cleaned up in the editorial process pretty soon.

--lars
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES4 draft: Object

Andrea Giammarchi
In reply to this post by Garrett Smith
Garrett Smith wrote:
> obj = {dontenum length: 10} );
> vs.
>
> obj = {length: 10};
> obj.propertyIsEnumerable("length", false);
>
> Which is more ugly?
>
> Garrett
Of course I prefere the first line but these two cases are different.
I wonder if a builtin method will not cause more problems instead of
avoiding them.

What I mean is what is the expected behaviour in this case?

Object.prototype.propertyIsEnumerable("length", false);
// some stuff ... and then ...  
Object.prototype.propertyIsEnumerable("length", true);


I think Object.prototype is the perfect case scenario where this built in method could cause more chaos than ever, while the dontenum in declaration makes sense specially when I write my own object and/or prototoype and I would like that no one will be able to change my not enumerable property. So I guess built in method is error/conflicts/problems prone while the first one is quite safer (and at the same time, I do like to know if others add some Object.prototype, both to avoid conflicts, problems, and errors)

These are only my 5 cents to this interesting discussion.

Kind Regards




--
---------------------------------
Zend Certified Engineer
ActionScript 2.0 Certified Developer
Web 2.0 Specialist
---------------------------------
Cel. +39 338 7621067

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

RE: ES4 draft: Object

Lars Hansen-3
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Andrea
> Giammarchi
> Sent: 7. mars 2008 00:25
> To: [hidden email]
> Subject: Re: ES4 draft: Object
>
> Garrett Smith wrote:
> > obj = {dontenum length: 10} );
> > vs.
> >
> > obj = {length: 10};
> > obj.propertyIsEnumerable("length", false);
> >
> > Which is more ugly?
> >
> > Garrett
> Of course I prefere the first line but these two cases are different.
> I wonder if a builtin method will not cause more problems
> instead of avoiding them.
>
> What I mean is what is the expected behaviour in this case?
>
> Object.prototype.propertyIsEnumerable("length", false); //
> some stuff ... and then ...  
> Object.prototype.propertyIsEnumerable("length", true);

Clearly length is meant not to be enumerated between the first call and
the second call.  We might want to consider pinning down what would
happen if an enumeration of an object is going on when the
enumerabilitiy of one of its properties is changed.  The details of that
would likely be compatible with what happens if a property is deleted or
added during enumeration, and the meaning of that is already defined in
ES3 (unvisited deleted properties are not visited; added properties may
or may not be visited).

> I think Object.prototype is the perfect case scenario where
> this built in method could cause more chaos than ever, while
> the dontenum in declaration makes sense specially when I
> write my own object and/or prototoype and I would like that
> no one will be able to change my not enumerable property.

Which is only one of the problems we're trying to solve, though.

> So
> I guess built in method is error/conflicts/problems prone

But it solves a problem that it's important to solve and that is not
solved declaratively.

> while the first one is quite safer (and at the same time, I
> do like to know if others add some Object.prototype, both to
> avoid conflicts, problems, and errors)
>
> These are only my 5 cents to this interesting discussion.

Appreciated.

--lars
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES4 draft: Object

Yuh-Ruey Chen
In reply to this post by Brendan Eich-2
Brendan Eich wrote:
> To avoid injecting a public name into Object.prototype, we could put  
> a new "setPropertyIsEnumerable" (yechh) name in the __ES4__  
> namespace. Then there's no breaking change. We do this already, of  
> course, but not for property attribute fiddling.
>  

Since enumerability only applies to for-in, how about the iterator
namespace? Object.prototype.iterator::setPropertyIsEnumerable(prop,
enable). For consistency, you could also have
Object.prototype.iterator::isPropertyEnumerable(prop) which delegates to
Object.prototype.isPropertyEnumerable(prop).

> An alternative we've discussed, which Ian also brought up: add a  
> keyword for declaring DontEnum properties.

This dontenum modifier can be used in addition to the method for
convenience - it would make class declarations cleaner.

But despite that, I think dontenum is inelegant. Its only effect would
be on the default enumerator, which is only one iterator, and AFAIK is
not special at all. IMO, it isn't worth the bloat. If there was a way to
define such modifiers within script, then I think the dontenum modifier
would be nice. If such a capability is planned for a future ES edition,
then I think dontenum is fine.

-Yuh-Ruey Chen
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES4 draft: Object

Brendan Eich-2
On Mar 7, 2008, at 1:14 PM, Yuh-Ruey Chen wrote:

> Brendan Eich wrote:
>> To avoid injecting a public name into Object.prototype, we could put
>> a new "setPropertyIsEnumerable" (yechh) name in the __ES4__
>> namespace. Then there's no breaking change. We do this already, of
>> course, but not for property attribute fiddling.
>>
>
> Since enumerability only applies to for-in, how about the iterator
> namespace?

Good suggestion.

Here's something I wrote a while ago (minor edits to update for  
context) that attempts to subsume enumerability under namespacing:

If we say enumeration considers only public non-DontEnum properties,  
then DontEnum is always true for namespaced props. Mixing DontEnum  
magic into the

obj = {var dontDel: 42, const RO_AND_DD: "foo"}

idea is wrong -- these should be public and enumerable as other  
properties in object initialisers are, by default. But we are *this*  
close to eliminating an independent DontEnum attribute. The problem  
is how to express public + DontEnum.

Suppose we had a predefined, open namespace, say dontenum  (surely  
not the best name). If you write

obj = {dontenum::cant_see_me: 33}

then

for (i in obj) print(i)

shows nothing. But

obj.cant_see_me

works, because dontenum is always open. No more need for an  
orthogonal DontEnum attribute.

Instead of

obj.propertyIsEnumerable('i_want_to_hide', false)

users would just say

obj.dontenum::i_want_to_hide = ...

(typically obj is a prototype object and ... is a function). The  
"setter" mode (second boolean arg) of propertyIsEnumerable is ugly  
(everyone says so, no one denies). It's arguably hard to use (because  
verbose). It's racy for users who have to call it after creating a  
property (there's a window in which the property is enumerable -- not  
a threading race per se, more low-level bug habitat and needless  
worry). It's a burden on implementations that want immutable  
attributes for props.

On the down side, you can't just add

obj.dontenum::foo = function () {...}

to ES3 code that runs in ES3-only browsers, as you could with the  
propertyIsEnumerable hack. We should in any case design for the long  
run.

Note that any namespace would hide a property from enumeration;  
dontenum is not magic in that sense, only in that it is predefined  
and open by default (again, its name is a strawman).

For the long run, rationalizing dontenum via namespaces seems good to  
me.

> Object.prototype.iterator::setPropertyIsEnumerable(prop,
> enable). For consistency, you could also have
> Object.prototype.iterator::isPropertyEnumerable(prop) which  
> delegates to
> Object.prototype.isPropertyEnumerable(prop).

Clever relocation of "is" in the predicate names ;-). We're probably  
stuck with propertyIsEnumerable.

>> An alternative we've discussed, which Ian also brought up: add a
>> keyword for declaring DontEnum properties.
>
> This dontenum modifier can be used in addition to the method for
> convenience - it would make class declarations cleaner.

True of a namespace already, note.

> But despite that, I think dontenum is inelegant. Its only effect would
> be on the default enumerator, which is only one iterator, and AFAIK is
> not special at all. IMO, it isn't worth the bloat. If there was a  
> way to
> define such modifiers within script, then I think the dontenum  
> modifier
> would be nice. If such a capability is planned for a future ES  
> edition,
> then I think dontenum is fine.

What do you think of the only-public-properties-are-enumeable idea?

Obvious problem to be solved: public means several things: "no  
namespace" (backward compatible) vs. "public in this package or  
class". We should discuss this more.

/be

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES4 draft: Object

Yuh-Ruey Chen
Brendan Eich wrote:

> Suppose we had a predefined, open namespace, say dontenum  (surely  
> not the best name). If you write
>
> obj = {dontenum::cant_see_me: 33}
>
> then
>
> for (i in obj) print(i)
>
> shows nothing. But
>
> obj.cant_see_me
>
> works, because dontenum is always open. No more need for an  
> orthogonal DontEnum attribute.
>
> Instead of
>
> obj.propertyIsEnumerable('i_want_to_hide', false)
>
> users would just say
>
> obj.dontenum::i_want_to_hide = ...
>  

Interesting and clever proposal. Some thoughts:

- It would become harder to change the enumerability of a property
(compared to a enumerability method): |obj.prop=obj.dontenum::prop;
delete obj.dontenum::prop;| That said, I'm not sure there are many use
cases that involving changing enumerability after the prop's
enumerability is initially defined.

- If you add setPropertyIsEnumerable(), how would that interact with
this? Would it change the namespace as described above, or just toggle
the hidden DontEnum attribute?

- Users may think this dontenum namespace is magical and yet another
thing to keep in mind, when it really just relies on the namespace trick
you mentioned. With the introduction of classes and namespaces, the
rules of enumerability are already more complex, so this adds to the
cognitive load slightly. BTW, if setPropertyIsEnumerable() is added,
would it be possible to make fixtures enumerable? Enumerability is
orthogonal to static analysis (which fixtures are meant to help with),
so I don't see why not.

- The name sucks :p

> > Object.prototype.iterator::setPropertyIsEnumerable(prop,
> > enable). For consistency, you could also have
> > Object.prototype.iterator::isPropertyEnumerable(prop) which  
> > delegates to
> > Object.prototype.isPropertyEnumerable(prop).
>
> Clever relocation of "is" in the predicate names ;-). We're probably  
> stuck with propertyIsEnumerable.
>  

Honestly, that wasn't intentional - it just came off my fingers naturally :)

-Yuh-Ruey Chen
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES4 draft: Object

Brendan Eich-2
On Mar 7, 2008, at 6:30 PM, Yuh-Ruey Chen wrote:

> Interesting and clever proposal. Some thoughts:
>
> - It would become harder to change the enumerability of a property
> (compared to a enumerability method): |obj.prop=obj.dontenum::prop;
> delete obj.dontenum::prop;| That said, I'm not sure there are many use
> cases that involving changing enumerability after the prop's
> enumerability is initially defined.

There are no valid use-cases IMO -- what Prototype et al. want is a  
way to create DontEnum properties on (standard or not) prototype  
objects _ab initio_.

> - If you add setPropertyIsEnumerable(), how would that interact with
> this? Would it change the namespace as described above, or just toggle
> the hidden DontEnum attribute?

I would withdraw that proposed extension (under any API) in favor of  
this one.

> - Users may think this dontenum namespace is magical and yet another
> thing to keep in mind, when it really just relies on the namespace  
> trick
> you mentioned. With the introduction of classes and namespaces, the
> rules of enumerability are already more complex, so this adds to the
> cognitive load slightly.

Slightly, but it takes away the magic DontEnum attribute, formerly  
hogged by the specification and magic predefined objects.

> BTW, if setPropertyIsEnumerable() is added,
> would it be possible to make fixtures enumerable? Enumerability is
> orthogonal to static analysis (which fixtures are meant to help with),
> so I don't see why not.

This gets to the heart of the public vs. public-in-context-of-class-
or-package issue. We need to sort this out to find out exactly how  
orthogonal enumerability is, as well as decide how flexible it should  
be.

> - The name sucks :p

Indeed. How about 'hidden' or 'nonEnumerable'?

/be

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES4 draft: Object

zwetan-3
here some thought

why not have a global utility function, maybe in the magic namespace

SetPropertyFlag( reference:Object, name:*, setflag:int, unsetflag:int
= 0 ):Boolean

the flag could have this logic

| decimal | bitFlag | ReadOnly | DontDelete | DontEnum |
|              0|       000|                no|                  no|
              no|
|              1|       001|                no|                  no|
            yes|
|              2|       010|                no|                yes|
             no|
|              3|       011|                no|                yes|
           yes|
|              4|       100|              yes|                  no|
             no|
|              5|       101|              yes|                  no|
           yes|
|              6|       110|              yes|                yes|
            no|
|              7|       111|              yes|                yes|
          yes|


some usages:

someobj = { foo:123, bar:456 };

SetPropertyFlag( someobj, "foo", 0x110 );
SetPropertyFlag( someobj, ["foo","bar"], 0x001 );
//etc.


I personally would like to be able to do that also on the prototype
SetPropertyFlag( myAlmostNativeObject.prototype, [ "some",
"properties", "to", "protect" ], 0x011 );


cheers,
zwetan
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES4 draft: Object

Brendan Eich-2
On Mar 7, 2008, at 7:27 PM, zwetan wrote:

> here some thought
>
> why not have a global utility function, maybe in the magic namespace
>
> SetPropertyFlag( reference:Object, name:*, setflag:int, unsetflag:int
> = 0 ):Boolean

No, sorry -- DontDelete upholds important integrity properties (like,  
you may not replace a setter for window.location). This over-
generalizes in a dangerous and unwanted way.

The goal is to find the minimum amount of mutating meta-programming  
sharpness for this "make certain properties non-enumerable" tool. If  
it can be done with a one-time namespace qualification step, that wins.

/be

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
12345