Axel Rauschmayer wrote:
On Aug 9, 2012, at 18:48 , Allen Wirfs-Brock <[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
home: rauschma.de <http://rauschma.de>
twitter: twitter.com/rauschma <http://twitter.com/rauschma>
blog: 2ality.com <http://2ality.com>
Herby
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
