Protected Protocol

David Bruant bruant.d at gmail.com
Tue Apr 3 01:49:02 PDT 2012


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?

>> 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?
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.

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


More information about the es-discuss mailing list