On Thu, Jul 1, 2010 at 11:13 AM, Mark S. Miller <[email protected]> wrote:
> On Thu, Jul 1, 2010 at 8:24 AM, Brendan Eich <[email protected]> wrote: > >> On Jul 1, 2010, at 2:13 AM, Mark S. Miller wrote: >> >> On Wed, Jun 30, 2010 at 9:09 PM, Brendan Eich <[email protected]>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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > -- Text by me above is hereby placed in the public domain Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
