Controlling DontEnum (was: ES4 draft: Object)

Peter Hall peter.hall at
Tue Mar 11 14:32:47 PDT 2008

If there is no method to make a property enumerable again (which I now
agree is better not to exist) it feels somehow bad to be able to make
a property non-enumerable after its declaration.


let a = {b:2, c:3};
for(let s in a){
 print(s); // b, c
for(let s in a){
 print(s); // c

It seems wrong that the code should run once one way, and then another
way, but there be no way back. It's not so much that I think there
should be a way back, but I'd rather that than this, which I consider
a weird situation. Also the double underscores are really ugly

Perhaps you can't achieve this without new syntax, but the declarative
approach seems cleanest and not prone to this sort of anomaly. If new
syntax could be considered, an |enumerable| attribute, complemented by
a |!enumerable| attribute seems very clean.

type T = {enumerable a:int, b:int};
let t:T = {a:1, b:2}:T; // a is enumerable, b is not

let s = {a:1, !enumerable b:1}; // a is enumerable, b is not

class C {
  enumerable var p;


On Tue, Mar 11, 2008 at 7:45 PM, Brendan Eich <brendan at> wrote:
> Here is a modest proposal based on Mark's and Maciej's messages:
>  Goal: A detectable method requiring no new syntax to set the DontEnum
>  attribute on an existing property.
>  Goal: Avoid breaking any existing ES3 code that might depend on a
>  plainly named method not being predefined.
>  Anti-goal: The ability to turn off DontEnum where it has been set on
>  predefined properties.
>  Proposal: Add Object.prototype.__makePropertyNonEnumerable__(name),
>  defined as if by:
>      Object.prototype.__makePropertyNonEnumerable__ = function (name) {
>          if (this has a direct property identified by name) {
>              set the DontEnum attribute for this[name];
>              return true;
>          }
>          return false;
>      }
>  Note that if this has a direct property identified by name, but this
>  [name] already has the DontEnum attribute, then the function returns
>  true. The specification with prose of setting DontEnum would occur
>  redundantly in this case, but it is not observable in ES3 or ES4 as
>  proposed, so for simplicity I left out a test of DontEnum to avoid a
>  redundant set.
>  The use of a __-bracketed name satisfies the second goal, but it
>  would be a problem for Caja or similar. This is an issue where I
>  would appreciate Mark's feedback.
>  Comments welcome.
>  /be
>  _______________________________________________
>  Es4-discuss mailing list
>  Es4-discuss at

More information about the Es4-discuss mailing list