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

[Mark S. Miller]

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 ;).



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

The agreed Harmony goal of "Provide syntactic support for high integrity
patterns", 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.


>
> Ok, that could be answered by arguing that Object.create needs different
> defaults for different use-cases from those other property-creating forms.
>
> But then the current thread brought up a Rhino extension that does not use
> the high-integrity defaults. So here we are. What is the common case, in
> current best practices? Is it really high-integrity with opt-out?
>
> /be
>
>
>
>>
>> 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 mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
>
> --
>     Cheers,
>     --MarkM
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


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