On 01.11.2011 21:57, Brendan Eich wrote:
On Nov 1, 2011, at 10:47 AM, Dmitry Soshnikov wrote:
The technique I showed of course initially is designed to be used
with class-system; though, I think it can be adopted to class-free
system as well.
We're not going to delete and restore. That's a non-starter for
performance and observable mutation reasons.
If you think something can be adapted, you have to show how. At this
point we don't need more assertions.
Well, at least I showed that the problem which so loudly sound here (w/o
seeing alternative solutions) isn't actually the problem -- even for a
library.
When I was showing it, it was just a reaction on the "big" problem
issued by Dave and others, it wasn't the proposal "let's standardize
it". Of course I as well understand that it's not good for performance.
And the point b) with "statically attached" class for a method, yes, it
also was here for years and can be implemented in any ES3 library (with
using `caller` which though is deprecated for user level, super calls
were more than elegant --
https://github.com/DmitrySoshnikov/def.js/blob/master/def.js#L80).
I noticed that I noticed, the current classes syntax with <|
}.prototype.{ }.constructor.{ will (OK, IMO) afraid the users (seems
mostly from classes the thread is started, not just super calls).
Dmitry.
/be
Dmitry.
If Dave (and you) is talking about the problem of i-looping at
resolving deeper than 2nd level super-calls, then even call-stack
is not needed.
See this implementation: https://gist.github.com/1330574#L68 (with
delete-restore the parent link technique).
Usage level with examples (line 95):
https://gist.github.com/1330574#L95
_______________________________________________
es-discuss mailing list
[email protected] <mailto:[email protected]>
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
