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
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
