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

Reply via email to