Syntax Proposal: Allow Java-like Object Literals after constructor calls to set properties on created objects.

Mark S. Miller erights at
Wed Jun 30 19:37:54 PDT 2010

On Wed, Jun 30, 2010 at 4:31 PM, Brendan Eich <brendan at> wrote:

> On Jun 30, 2010, at 4:24 PM, Jürg Lehni wrote:
> > On 30 Jun 2010, at 23:32, Brendan Eich wrote:
> >
> >> On Jun 30, 2010, at 2:15 PM, Erik Arvidsson wrote:
> >>
> >>> Sorry, Object.create was a mistake.
> >>
> >> A bit harsh, but my point is not about tone -- it is that the mistake in
> your view is the default values for missing attributes being false, not
> true. Right?
> >
> > Rather than having missing boolean values default to true which somehow
> contradicts ES behavior when dealing with undefined boolean values
> (!undefined == true), I would have preferred if the properties were defined
> as their opposites, so default to false would make more sense: writable ->
> readOnly, configurable -> sealed, etc. But I guess it is what it is now.
> This was all discussed in the ES3.1 -> ES5 days, indeed. The ES1-3
> "DontDelete", "DontEnum", and "ReadOnly" names are awkward for being
> negative ("Dont", "-Only"), resulting in double negative phrasing when
> documenting and discussing.
> And you're right that attribute-property-missing -> undefined -> false has
> an effect here. If we had kept the ES3 negative names, we could have
> defaulted to false and Erik (I think) would not find Object.create a mistake
> -- but then the high-integrity-by-default fans would be put out. Those fans
> should speak up if they care to defend against the "mistake" charge.

Fine. Had it defaulted to low integrity, that would have been a mistake.
Erik & I know we disagree on this.

> Anyway, ES5 is done. Life goes on, though, with Harmony. There's not much
> that can be done about the default attribute values and the sense of their
> names, Same for Object.keys vs. Object.getOwnPropertyNames
> method-naming-style disparity. Food for thought, in order to do better in
> the future.

The naming inconsistency here actually is a mistake. I do regret it, but I
also agree it's too late to fix it.

> /be
> _______________________________________________
> es-discuss mailing list
> es-discuss at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list