Re: mixins etc.

Graeme Rocher schrieb:
[...]
> +1 great write-up Jochen.

thx, let me try another writeup

let us say R stays for runtime and C for compile time, H for affecting
the hierarchy, N for not affecting the hierarchy, then we get four
possible variations (CN, CH, RN, RH) and I will try to imagine some
scenarios and which form they would fit. Ah yes... since I need to name
it somehow to address it in general, I will for now call such a
mixin/trait/whatever class toolbox.

(S1) The user has a set of methods he wants to apply to different
classes with implementing these methods only in the "toolbox" -> CN, CH,
RN, RH

Since all of them will do this Job let us refine the scene... Let us say
(S2) The class is a Java class and we want to add methods to be able to
call them later -> RN, probably RH

(S3) A user wants to know if our toolbox got applied to a certain class
-> no restrictions, it could be done via a special instanceof or with a
MetaClass method. If a instanceof from Java should work here, then CH

(S4) The class contains an abstract method form the super class and our
tool box should be used to implement this method -> CN, CH

(S5) The toolbox implements a certain interface and the class should
then implement this too -> RH,CH, in combination with the one before CH only

(S6) The user does not want that his toolbox gets influenced by another
toolbox. Id he wants to control that at source level -> CH, CN. If
controlled at runtime -> RH, RN

(S7) The user wants that an exception is thrown when he wnats to apply
his tools box, but this would redefine a method from another toolbox ->
RH, RN

(S8)The user wants to limit the "visibility" of his toolbox.
(S8a) per Thread -> none of these
(S8b) per class and subclasses -> all
(S8c) per package -> none

Maybe others can add usages and scenarios.... Anyway only S2 speaks for
a runtime construct atm... and that is more or less what a category
would do. A category would also cover S8a, while the proposed construct
seems to be addressing more S8b, but the difference is not very big,
since categories do also address S8b a bit.

I personally favor CH I must say, because the idea of being able to have
an automated implementation of interfaces and maybe AST transformations
is something I like.

then there are open questions, especially with the form without the
"self" reference.

(Q1) what happens to a private method in the toolbox?
(Q2) how to call the original method?
(Q3) can I maintain a static state in the toolbox?
(Q4) can I maintain a non static state in the toolbox?
(Q5) How will a closure resolve its methods/properties when in the toolbox?
(Q6) is the toolbox getProperty/setProperty/invokeMethod/missingMethod
method overwriting the one in the class th toolbox is applied to?
(Q7) can a toolbox provide a constructor?
(Q8) can a toolbox provide a static property/field
(Q9) can a toolbox provide a non static property/field
(Q10) is a private field in the toolbox also a field in the class the
toolbox is applied to?

Well, this is all I can think of within 5 minutes ;)

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
http://www.g2one.com/

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email