>> 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