On Tuesday, 2012-04-03 at 01:49 , David Bruant wrote: > Le 02/04/2012 17:59, Irakli Gozalishvili a écrit : > > Hi David, > > > > Your protected work reminds me a lot of what we did with `namespcase` > > module in jetpack: > > https://addons.mozilla.org/en-US/developers/docs/sdk/latest/packages/api-utils/namespace.html > > Which I also blogged about some time ago: > > http://jeditoolkit.com/2012/03/15/namespaces.html#post > > > > As soon as I first wrote "Protected(this)", I thought of Jetpack namespaces > :-) > > I remember that one of your complaints about namespaces was that inheritance > was not supported. Do you think there is a workable middleground between > namespaces and what I've showed here that would have the benefits of > namespaces and inheritance? >
Adding inheritance support turned out to be pretty easy and there is a patch in a review that would add support to it: https://github.com/mozilla/addon-sdk/pull/375 > > > I have made obvious by juxtaposing both examples that JavaScript > > > requires from the programmer to choose between encapsulation and > > > inheritance. Indeed, as demonstarted above, encapsulation requires a > > > shared scope. > > > > > > > > > > > > > > > I totally agree that with this pain point, but hopefully private names will > > help this. What drove me to reimplement something like Java's protected is > > that I fear private names won't be enough. > > Basically, if an object o is an A and all As are Bs, if you only have private > names, then, o's methods inherited from B can access private names related to > B. o's methods inherited from A can access private names related to A. > However, A methods can access private names related to B only if B shares > them (like the "secret" and "age" of my example). B can share them "globally" > (in the sense of "to anyone", not necessarily as properties of the global > object), which effectively makes the private names no longer private, but > only unique, or A and B need to share a common scope which, in my opinion, > does not scale (it forces A and B to be in the same file which is not always > an option if you want to use code written in a library) > > > > Still I think that there are other expression problems with classes that > > could be elegantly solved using clojure like protocols that I have posted > > other day: > > > > http://jeditoolkit.com/2012/03/21/protocol-based-polymorphism.html#post > > https://mail.mozilla.org/pipermail/es-discuss/2012-March/021603.html > > > > > > I had completely missed that. > > > Unfortunately I did not got much of a feedback ;) I'll need to watch the > > video and read more, but that's an interesting idea. > > "Note: That even though both Event and Installable protocols define functions > on and off. Also Object implements both still protocols, but there no > conflicts arise and functions defined by both protocols can be used without > any issues!" > => This part is rather intriguing. I'm afraid this may lead to confusion. > When I write .on, am I installing? adding a listener? Doing both? They are different functions (not the methods). I was asked a similar it in the question and I replied there: http://jeditoolkit.com/2012/03/21/protocol-based-polymorphism.html#comment-474857390 https://gist.github.com/2175647 > Also, how are name conflits resolved? Regardless of the exact choice, it > seems to be implicit and thus certainly confusing. On that aspect, I would > tend to prefer traits or a traits-like solution. There are no conflicts that's a whole point :) > > David
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
