Syntax Proposal: Allow Java-like Object Literals after constructor calls to set properties on created objects.
Allen Wirfs-Brock
Allen.Wirfs-Brock at microsoft.com
Thu Jul 1 12:56:04 PDT 2010
> From: Erik Arvidsson
> This is clearly a usability win, even with the ugly underscores. With Allens
> proposal that would become:
>
> var o = {
> [proto: Foo.prototype]
> _a: 1,
> get a() { return this._a; },
> set a(a) { this._a = a; }
> };
Or in combination with Dave Herman's names proposal something like:
private _a;
var o = {
[proto: Foo.prototype]
_a: 1,
get a() { return this._a; },
set a(a) { this._a = a; }
};
Or
var o = {
[proto: Foo.prototype, private: _ a]
_a: 1,
get a() { return this._a; },
set a(a) { this._a = a; }
};
Or maybe even just:
var o = {
[proto: Foo.prototype]
private _a: 1,
get a() { return this._a; },
set a(a) { this._a = a; }
};
> -----Original Message-----
> From: es-discuss-bounces at mozilla.org [mailto:es-discuss-
> bounces at mozilla.org] On Behalf Of Erik Arvidsson
> Sent: Thursday, July 01, 2010 12:17 PM
> To: Mark Miller
> Cc: Mark S. Miller; Jürg Lehni; Brendan Eich; es-discuss
> Subject: Re: Syntax Proposal: Allow Java-like Object Literals after constructor
> calls to set properties on created objects.
>
> A lot of discussion since I last checked in...
>
> I apologize for the harshness. I do agree that Object.create is useful and I agree
> that the default values for the property descriptor is acceptable even though
> having read only be the default is painful but consistency trumps that one.
>
> My main issue is actually that Object.create is such a low level construct. It is
> very good for library authors to hide it behind a friendlier interface. I wish
> Object.create was called something more obscure and Object.create was
> targeting end users. Instead of passing a map of property descriptors an object
> would be passed. I just find the extra layer of object literals too much.
>
> var o = Object.create(Foo.prototype, {
> _a: {
> value: 1,
> writable: true,
> },
> a: {
> get: function() { return this._a; },
> set: function(a) { this._a = a; },
> enumerable: true
> }
> };
>
> If Object.create was created with users in mind it might have looked something
> like:
>
> var o = Object.create(Foo.prototype, {
> _a: 1,
> get a() { return this._a; },
> set a(a) { this._a = a; }
> });
>
> Looking forward, I like where Allen is going with the extended object literals.
> Today, we can do the following in most browsers (relying on the __proto__
> extension).
>
> var o = {
> __proto__: Foo.prototype,
> _a: 1,
> get a() { return this._a; },
> set a(a) { this._a = a; }
> };
>
> This is clearly a usability win, even with the ugly underscores. With Allens
> proposal that would become:
>
> var o = {
> [proto: Foo.prototype]
> _a: 1,
> get a() { return this._a; },
> set a(a) { this._a = a; }
> };
>
>
> On Thu, Jul 1, 2010 at 11:40, Mark Miller <erights at gmail.com> wrote:
> >
> >
> > 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
> >
> >
>
>
>
> --
> erik
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
More information about the es-discuss
mailing list