>>  1) Remove the feature entirely from ES4 (as part of the "judicious
>>  feature cuts" process) until a more appropriate syntax is found

Setting dontEnum is immensely valuable as a framework developer. I realize
that is not a very technical argument, but controlling dontEnum is of more
value than many of the other features in ES4, and would certainly hope it is
not omitted.

> So long as setPropertyIsEnumerable is a method of Object.prototype, it
> raises the otherwise pointless question of the meaning of overriding
> it. At the last ES3.1 face-to-face, we agreed instead on the following
> static method on Object, as recorded at
> <http://wiki.ecmascript.org/doku.php?id=es3.1:targeted_additions_to_array_string_object_date>:
>
> -------------------------
> Object.dontEnum(object, memberName)

I realize I wasn't there (at the ES3.1 F2F, only called in), but why was
this discussed for ES3.1? I thought the page you are referencing was simply
items that hadn't been cleaned up yet, since it clearly does not subset ES4
(as I noted in my comments on that page). If we desire that this be a part
of ES3.1, it should be brought up as a proposal for ES4, so that ES3.1 can
safe subset it, rather than creating new divergent features for ES3.1.
Frankly, I like the idea of using "Object.dontEnum(object, memberName)",
that sounds great to me, but it should be an ES4 proposal first and should
not be considered for inclusion in ES3.1 unless and until accepted by ES4.
BTW, Another possible syntax could be:
Object.setAttribute(object, memberName,attributeFlag)
which could be used to set the dontEnum, readOnly, and dontDelete flags and
probably more closely follows the internal structure of implementations as
well.
Thanks,
Kris


_______________________________________________
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Reply via email to