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

Thu Jul 1 11:40:44 PDT 2010

On Thu, Jul 1, 2010 at 11:13 AM, Mark S. Miller <erights at google.com> wrote:

> On Thu, Jul 1, 2010 at 8:24 AM, Brendan Eich <brendan at mozilla.com> wrote:
>
>> 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*.
>>
>
> As we're moving away from object environment records, I take the world of
> variables and the world of properties to be distinct.
>
> For variables in Harmony, we're introducing "const" and "let" and
> effectively deprecating "var". For a variable that's never assigned to, I
> suggest that "const" is better style. Then those variables declared with
> "let" stand out, signaling to the programmer "Assume this variable may be
> assigned to".
>
> Named function expressions already bind the function name with a const
> (unassignable) binding. Regarding named function declarations, I find <
> http://wiki.ecmascript.org/doku.php?id=strawman:const_functions>
> attractive. IIRC, so do you. I've just added a "High Integrity Factories"
> example to the end of that page. That example does demonstrate my one regret
> about the definition of Object.create() -- that it defaults to creating an
> extensible object, requiring a separate Object.freeze() to complete the
> second example. Because of this "mistake", the complete second example is no
> longer pleasantly terse.
>
>
>
>> 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.
>>
>
> Glad to hear it. Our positions are closer than I'd feared. My main concern
> in the design was ensuring that configurability defaulted to false. Besides
> integrity, this should also enable various optimizations. When combined with
> non-extensibility, it gives us objects of fixed state.
>

I meant "fixed shape". An especially confusing typo in this context, sorry.

> That said, I still think writable defaulting false was the right decision.
>
>
>>
>> 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.
>>
>
> OTOH, the Classes as Sugar to-be-strawman at <
> https://mail.mozilla.org/pipermail/es-discuss/2009-March/009115.html>
> expands to defining frozen instances. To get the scoping benefit that Peter
> Michaux suggested -- where public instance members are also in scope as
> variables in the defining context -- to work for mutable variables/instance
> fields, the only non-with-way to do that is to have the instance fields be
> defined as accessors accessing the variable. This is consistent with the
> instance being frozen.
>
>
>>
>>
>> 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 :-|.
>>
>
>
> See <http://wiki.ecmascript.org/doku.php?id=harmony:harmony#means> 2.II.
> s/support/conveniences/
>
>
>>
>>
>> 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,
>>
>
> It helps a lot. Thanks. Our positions are indeed fairly close.
>
>
>
>>
>> /be
>>
>
>
>
> --
>     Cheers,
>     --MarkM
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>

-- 
Text by me above is hereby placed in the public domain

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