strawman for the := operator

Herby Vojčík herby at mailbox.sk
Thu Aug 9 14:30:52 PDT 2012



Axel Rauschmayer wrote:
> On Aug 9, 2012, at 18:48 , Allen Wirfs-Brock <allen at wirfs-brock.com
> <mailto:allen at wirfs-brock.com>> wrote:
>
>> There are irregularities around the edges such as when assignment auto
>> defines a missing property but they are of minor importance if a
>> programmer clearly understands where they are defining abstractions
>> and where they are consuming abstractions.
>
> Let’s, simplifyingly, call people who create abstractions “library
> authors” and people who use abstractions “normal developers”. It does
> make sense to give the latter group specialized tools that help them do
> their work. But I’d like to take a step back and ask the following question.

It's a very big simplification. There is no "normal developer" in any at 
least middle-sized project, imnsho. We are all "library authors" most of 
the time - we create abstractions.

So I see the rest of the original post as not at all that strong as it 
may look.

On the contrary, we should definitely help "abstraction writers" to be 
able to do their work with ease and, which is connected, to help 
"consumer developers" become "abstraction writers" more easily.

I definitely agree with Allen's (especially the last sentence):
> I think succinctness is a very important considerations in this case. One of the root problems is that it is just too darn easy to say = rather than Object.defineProperty or Object.update.  Even those of us who know better take the shortcut and use = whenever we think we can get away with it.
>
> I don't think any of the proposed procedural APIs are likely to change that habit.  I think := stands a change.  I'm pretty sure it would  change my behavior.

Axel Rauschmayer wrote:
> Where can the assignment operator (=) currently bite you? I’ve come up
> with the following list:
>
> 1. Copying properties, where you always want to override and update
> [[Home]] (for super references).
> 2. Patching non-writable configurable properties
> 3. Adding a property to an object (without invoking the setter), e.g. to
> add a unique ID to an object you put into a collection
> 4. Constructors should always define properties, not assign them. If you
> add instance methods, [[Home]] and [[MethodName]] must be set up properly.
>
> Analysis:
>
> (1) is only relevant for library authors. Normal developers can use
> Object.update() or similar (including an operator).
>
> (2) is only done by library authors. They can use Object.define() et al.
>
> (3) seems like an edge case, mostly relevant to library authors. With an
> object you know, assignment seems OK. With an object you haven’t
> created, overriding a setter with a data property seems like asking for
> trouble, anyway. In ES.next, private names should solve this problem.
>
> (4) matters for normal developers, but only for instance methods. If I
> am not mistaken, instance methods are currently mostly used for
> Crockford-style privacy and will be much less common once we have
> private names. Furthermore, it is difficult if not impossible to add an
> instance method with a super-reference in ES.next. But that might change
> later.
>
>
> Did I miss anything? I agree that we should protect normal developers
> from getting bitten by the assignment operator. But whatever the
> solution, it has to be dead-simple. Perhaps there are smaller measures
> that can be taken so that normal programmers don’t have to understand
> the difference between definition and assignment. Which is subtle,
> because by auto-creating missing properties, assignment has taken on
> some of definition’s responsibilities.
>
> --
> Dr. Axel Rauschmayer
> axel at rauschma.de <mailto:axel at rauschma.de>
>
> home: rauschma.de <http://rauschma.de>
> twitter: twitter.com/rauschma <http://twitter.com/rauschma>
> blog: 2ality.com <http://2ality.com>

Herby


More information about the es-discuss mailing list