strawman for the := operator

Brendan Eich brendan at mozilla.org
Wed Aug 8 11:40:04 PDT 2012


Russell Leggett wrote:
> On Wed, Aug 8, 2012 at 12:35 PM, Brendan Eich <brendan at mozilla.org 
> <mailto:brendan at mozilla.org>> wrote:
>
>     Erik Corry wrote:
>
>         Hi
>
>         This proposal offers a way to get around some of the strange
>         semantics
>         of '=', specifically the way read-only properties and setters on
>         objects in the prototype chain can restrict what you can do on the
>         receiver of an assignment.
>
>
>     This is "strange" only insofar as you can't say what you mean if
>     you want to override. There's no law of nature requiring = to
>     override, though.
>
>
> I actually think that the behavior of = makes total sense in regards 
> to setters and read-only properties. If that was not the behavior, it 
> would be pretty silly. If = on a setter overrode the setter, it would 
> defeat the point of the setter. Same with read-only properties.

To be fair, the issue is not overridng "own" read-only or setter-based 
properties. It is overriding delegated properties.

But there too one can argue, and extant code wants (see WebIDL), 
assignment-invoking-a-setter to abstract over prototype delegation. 
That's enough for me to want non-writable assignment failure to match. 
Others disagree, but I think they're doing so out of pragmatism more 
than principle (the Caja/SES frozen built-in prototypes problem).

Pragmatism is fine, but for the long run I think we are better off 
providing both assign and define "screwdrivers" (to use Kevin Smith's 
metaphor). Then in principle everyone wins. There's still a hard case 
for Caja on older browsers, but that's (a) temporary; (b) solvable at 
some cost (as Mark et al. cleverly have indeed solved it).

So I think the long-run right answer, given the sunk cost non-fallacy of 
Caja having to deal with most browsers in the field rejecting write 
attempts that would shadow a non-writable proto-property, is to level 
the field: = and :=, Object.assign and Object.define if appropriate. I'm 
not sure batch assignment pays for itself, but we can check on Dart's 
experience and user-test and argue that one separately.

>     Assigning != defining in ES5, even in reality in fixed
>     implementations of ES3, and in truth going back to the first JS
>     implementation: proto-setters (internal, hidden) are invoked by
>     assignment, readonly proto-props prevent = being used to override
>     on a delegating object (silent failure, of course, due to lack of
>     try/catch).
>
>     What I'm getting at: is assignment != defining strange, or is the
>     lack of expressiveness that left JS with = but not := strange, or
>     is = not defining strange? I didn't want to assume the last was
>     what you meant, since it is not obvious and not the only possible
>     strangeness or asymmetry.
>
>
> I think the problem is really the conflation of = depending on the 
> context. In more classical languages, there is a separation between 
> methods and data. Overriding would never be done with =. If it was 
> data, it would set the value of the field for that instance, and if it 
> was defining a method, that would typically be done as an extension. I 
> think that a happy path for users could aid in untangling the 
> confusion, but I think we have to be clear about what that happy path 
> should be.

It's hard to disagree :-).

>            However it has some strangeness itself:
>
>         * There is little point in having read-only properties if the
>         common
>         way to do assignment is :=.  := will just walk all over a
>         read-only
>         property.
>
>
>     No, readonly properties must be {writable: false, configurable:
>     false} to have integrity, and := cannot redefine a
>     non-configurable property.
>
>
> This brings me to an important point. I think we are conflating too 
> much the ease of definition with the intent of Object.extend. Allen's 
> strawman actually says := is similar in intent but not semantics. I 
> don't like that, and I think it adds to the confusion. I think we have 
> three cases here.

Oh, I agree completely if the topic is Object.extend -- which is a 
well-know library method that uses assignment, not any ES5-only 
Object.defineProperty API.

>  1. You would like to mixin additional behaviors. This is commonly
>     done with something like Object.extend, but that typically relies
>     on [Put] semantics, but we really would like those to be defined.
>     Mixins are available in many languages in various forms. There are
>     many implementations for doing them in JavaScript and they are
>     fairly commonly used. Mixins typically involve a group of methods
>     which should always be mixed in together. Making super work
>     correctly here is important.
>

Agreed, mixins are a use-case to serve, not necessarily by anything we 
are currently discussing.

I disagree that Object.extend does "mixins" if the methods should always 
be mixed in together. It may be that when using PrototypeJS in the past, 
you could get away with using Object.extend this way. With ES5 you 
can't. See http://traitsjs.org/ for an ES5-based approach that enforces 
all-or-none-with-throw and other mixin properties.

Given the ability to specify non-configurability along with 
non-writability in ES5, := can be used for high-integrity mixins.

>  1. You would like to define a single property using a similar style
>     as =, but you want to make sure it is a definition instead of a put.
>

Object.defineProperty, but it's verbose and := seems a strict 
improvement to me.

>  1. You have several values that you would like to [Put] - basically
>     just a batch assignment.
>
> I believe that := is ill suited to straightening out these cases.

See above. I think your (1) is ill-defined, but for high-integrity cases 
you seem to want ("should always be mixed in together"), ES5 and any 
sugar such as := do help. For (2), := helps because there's no shorter 
way to specify attributes.

> I think it will commonly be needed for #3, but instead do definition. 
> Its convenience lends itself to abuse.

I doubt this. Arguments of the "developers will use it wrong" need 
evidence, and developers are smart. They learn.

/be


More information about the es-discuss mailing list