motivating <| as structure representation, not operator
axel at rauschma.de
Sat Nov 19 07:42:55 PST 2011
If I may, two suggestions: For longer posts, an executive summary with the main points might make sense (not sure if I’m always doing this, but I should). And if you can, a greater “column width” for your hard line breaks would be nice, too. I checked in Emacs where I’m happy with the column width and it is indeed wider than what you are doing.
> it has odd properties
> for an operator, such as "literal rhs only", "modify rhs".
> Both oddities could be addressed if TC39 would be willing to tackle object cloning. Then, <| could produce a clone of
> its rhs. But cloning with hidden and private state is tricky
> and might create new oddities while solving old ones. I'm
> not sure about this (see PS).
Cloning for prototype chains might be an easier problem to solve than general object cloning. Such cloning would be useful for composing prototype chains from existing objects.
> Ultimately, we might be able to talk about prototype chains in
> terms of <| only, without the need for [[prototype]] or __proto__
I like <| as an inheritance operator. If we are to extend (“subclass”) function exemplars then an abstraction of the complicated under-the-hood wiring is a good thing. But having a property name for the prototype is handy, too. Perhaps a public name (as in name object) can be introduced for it?
> (I'm thinking about blog posts here, which typically face the dilemma of talking about [[prototype]] vs 'prototype', to help
> readers in the long run while confusing them at first, or talking about __proto__, to be understood in the short run, with possible problems later).
Where human language usually fails me is when I initially explain prototypes in the __proto__ (or Object.create() or Self-ish) manner and then get to constructors. Then I talk about the constructor’s prototype to avoid the longish “the value of the prototype property of the constructor”. But that’s confusing! It’ll get worse should constructors become prototypes of each other in the future.
Dr. Axel Rauschmayer
axel at rauschma.de
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss