Allen Wirfs-Brock wrote:
On Mar 17, 2012, at 1:20 PM, Herby Vojčík wrote:
Allen Wirfs-Brock wrote:
This has nothing to do with classes. It is just basic prototypal
inheritance and the semantics of the new operator and function
expressions.
Well, seems convincing... but nevertheless, I see it as a strange
special case... maybe good example is "bare"
function foo () {}
How would you write it using <| ?
If you do
Function <| function foo () {} // [[Prototype]] set right
you get wrong prototype.[[Prototype]]. If you write
Object <| function foo () {} // prototype.[[Prototype]] set right
you get wrong [[Prototype]].
You write it
Function.prototype <| function foo() {}
Yeah, my mistake... the one I did was wrong.
So it _has_ to do a lot with classes... anything taking 'new foo' into
account is taking classes into account.
...
Herby
* I know there is no real point in writing bare constructor functions
using <| at all - but it illustrates for me the problem - it cannot
embrace this trivial scenario, so ... it hints it may be problematic.
But it does embrace it, so maybe not so problematic after all...
Well, I did what I can to show it is problematic in general
x <| function () {}
case, where you simple want x as [[Prototype]] and generic .prototype,
but I probably failed to show you that it will backfire in future (don't
tell me "just don't have prototype property in x", if I get it via chain
of calls passing argument around, maybe from library user, than I am not
the owner of x).
You see this special-casing as a right semantics, based on that it is
natural, least-suprise... but really, if it cares about new X, it _is_
about classes, don't you see it (plain setting [[Prototype]] does not care)?
Herby
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss