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

[Brendan Eich]

On Jul 1, 2010, at 2:13 AM, Mark S. Miller wrote:

> On Wed, Jun 30, 2010 at 9:09 PM, Brendan Eich <brendan at mozilla.com> wrote:
> On Jun 30, 2010, at 7:37 PM, Mark S. Miller wrote:
> 
>> 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.
> 
> 
> Allen seems to agree with Erik. Is this just a matter of personal opinion?
> 
> More that just personal opinion. At this point I think there is good evidence that Allen agrees with Erik ;).

LOL, pronoun trouble. I meant by "this" the whole "X is a mistake... !X is a mistake" approach, which seemed in your mail to come down to he-said/I-said ;-).


>  
> The point that I don't see you responding to is that the Object.create defaults are opposite from what every other way of binding a property in the language uses.
> 
> Every other is two: 1) assignment, or 2) object literals.

3) Declaration by var/function -- makes non-configurable unless from eval, but *writable*.
4) Pre-defined bindings are mostly writable -- built-in constructors' 'prototype' properties are a notable exception.

Writability rather than configurability or enumerability is the bone of contention, I think. Of course all three default the high-integrity way in Object.create, and I wouldn't want to split them up, some defaulting to true while others to false.

What  I'm suggesting is that writable:false is what sticks out as less usable, especially for cases such as the Rhino object initializer extension recast using Object.create as in Allen's mail.


> These already make low integrity easy. Prior to ES5, high integrity was impossible. A new API introduced to support high integrity should also make it easy -- if it's not easy to be safe, few will. Low integrity remains easy through assignment and object literals.

Yes, this was the rationale and I went along with it -- still do. I'm not jumping up and down about "mistake" here, rather trying to draw out exactly what is at issue. Calling Object.create "a mistake" in full is excessive, since it has other useful features that are not considered broken AFAIK.

The way to make progress (for future extensions, nothing's going to change in ES5) is to tease out the compositional, reduced or "primitive" missing semantics we may want to add to the language, and not condemn composite extensions wholesale. We can then argue about usability and convenience more clearly.

So my disagreement in the end (as in my initial followup!) is with Erik for condemning all of Object.create. There's good stuff in there, even if the defaults are less usable for some (more familiar, like what you can do in JS today) use-cases.


> The agreed Harmony goal of "Provide syntactic support for high integrity patterns",

Don't see those words at http://wiki.ecmascript.org/doku.php?id=harmony:harmony -- but I won't quibble :-|.


> as well as the repeatedly stated desires for some kind of class construct going back to ES4, shows that we did not go far enough in making high integrity easy. But we did what we could within the ES5 constraints. I'm glad we didn't do less. The easy way should be the safe way. 

As Allen said, the defaults being different make Object.create less usable for approximating extensions such as the Rhino your-constructor-call-with-args+object-initialiser-for-extra-properties one. That's clear enough without assuming anything beyond what was in Rhino's extension, or in ES1-3 or JS as practiced today -- i.e., without assuming that the user wants higher integrity, specifically non-writable properties.

Object.create has great defaults for creating built-in-like properties, akin to built-in constructor 'prototype', and of course for creating even more heavily armored objects. No question! ;-)

So, in the category "bleeding obvious" (I hope), and without beating the issues in this thread to death no further, my conclusion is that the Rhino extension or something that fills its usability gap it wants new syntax and not Object.create. I do not mean to imply either that we should add the Rhino extension (mutatis mutandis), or that Object.create is "a mistake".

Hope this helps,

/be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100701/b65aaa95/attachment-0001.html>