Protected Protocol

Irakli Gozalishvili rfobic at gmail.com
Tue Apr 3 08:19:38 PDT 2012


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120403/15fcade7/attachment-0001.html>


More information about the es-discuss mailing list