r-proto-class

Dmitry Soshnikov dmitry.soshnikov at gmail.com
Tue Nov 15 12:02:11 PST 2011


On 15.11.2011 17:34, Jake Verbaten wrote:
> You fell for the broken super implementation trap 
> <http://jsfiddle.net/Wtx3E/1/>
>

By the way, forgot to mention. In dynamic languages it may be dependent. 
And it's actually a question what is a correct behavior -- early or late 
binding in this case. E.g. current Ruby (1.9.3-p0 Win) also shows 
"broken" in such an example:

class One
   def one
     two
   end
   def two
     print 'you win'
   end
end

class Two < One
   def one
     super
   end
   def two
     print 'broken'
   end
end

(Two.new).one # broken!

P.S.: though, I've tested the same example at work, and it seemed to me 
that it showed "you win". Don't know, perhaps I have some old version or 
Ruby at work. Anyway, in the newest version of Ruby the behavior used as 
shown above and it really depend what is wrong and what's not. Which way 
JS will choose -- it's another question; as we have seen, both variants 
can be implemented even in JS itself.

Dmitry.

> Your calling super methods with a value of `this` that has references 
> to methods you don't expect it to have. i.e. if any sub class shadows 
> a method of a super class, then every reference to method invocation 
> in the super class will invoke the method of the sub class rather then 
> the method of the class itself.
>
> super is not a beast you can implement trivially in ES. I actually 
> have a stackoverflow question 
> <http://stackoverflow.com/questions/8032566/emulate-super-in-javascript> 
> about super.
>
> You can't actually implement super without hard coupling a reference 
> between Parent and Child. inheriting a generic super method from a 
> prototype won't work as far as I know.
>
> On Tue, Nov 15, 2011 at 12:34 PM, Dmitry Soshnikov 
> <dmitry.soshnikov at gmail.com <mailto:dmitry.soshnikov at gmail.com>> wrote:
>
>     Hi,
>
>     <Just on the Rights of a bike-shedding :)>
>
>     R-proto-class is my quick experiment of yet another class lib for
>     ES5: https://gist.github.com/1366953
>
>     Main features are:
>
>      * Simple super calls (with mentioned before, but modified,
>     "delete-restore" parent link); used only for classes.
>
>      * using Object.create for inheritance (the main part of this lib
>     variant) -- at user-level a programmer uses native Object.create
>
>      * Class.new is a wrapper over Class.allocate and
>     Class.initialize. I.e. overriding <UserClass>.allocate you may
>     allocate different objects
>
>     It's just a lib, it's not proposed for standardization (you may
>     even not to comment on this letter, just take a look for a
>     curiosity); it's just shown again, that in both ES3 and ES5 we had
>     and have lib-versions of such sugar, including good class-level
>     super-calls. So again, if to talk about standardization, then the
>     standardized version (whichever it will be) should be at _least_
>     much better than all these libs. Including syntactically.
>
>     Cheers,
>     Dmitry.
>     _______________________________________________
>     es-discuss mailing list
>     es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>     https://mail.mozilla.org/listinfo/es-discuss
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111116/ae13db3b/attachment.html>


More information about the es-discuss mailing list