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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
