Peter Neubauer wrote: > http://www.slideshare.net/jboner/pragmatic-real-world-scala-45-min-presentation?type=powerpoint > > There is the concept of dynamic Mixins on slide 35. Is that good or bad?
This is a complicated one. I think we need to take a step back and look at the big picture, and ask what is going on, and why. For a real-world comparison, you cannot tell me that I know German, and start talking to me in German, no matter how much you are I would like it to be possible to do so. That is an ability that depends on the object and not the user, which is what dynamic Mixins are implying. However, as a counter-example, whenever you are dealing with someone speaking English, but you prefer to have the German translation of what is being said, you can put a babel-fish in your ear (or keep a dictionary handy), and then make up your mind of what is said based on that instead. In this case being able to say "now I want to add the English2German mixin to you" would be handy! The difference is where the mixin belongs, i.e. who "owns" it. In the first example I did not have the GermanSpeakingMixin, and I couldn't make use of it even if you gave it to me. In the second example you have not changed the object you, as a client, are dealing with, but have merely "enhanced" your perception of it. The English2German mixin is a part of *your* context, which you apply to the object without it knowing about it. However, anyone else using it doesn't know it, and might not even be able to use it even if they did see it. I think, therefore, that mixins should probably either be declared in the object itself (static mixins), *OR* the client should be able to specify to its context that "whenever I see an object that can do X(=speak english) let it also be able to do Y(=sound like german)". This is proper separation of concerns and responsibilities I think, and would still be able to be quite useful. As an example of this, current OOP practices say that numbers should have operators on them, such as "+" and "*" and so on. This is pure non-sense! Operators are part of an algebra, can be defined in any number of ways (depending on which algebra you choose), and in some cases they don't even apply to numbers at all (e.g. if you use numbers for street addresses the operator "*" has no meaning). Instead I think it would be more appropriate if a client could say "if I ever see a Number, then it should be able to do +, and here is how + is defined right now". The idea of Abilities that we have discussed might make it possible to get closer to this, as the list of Abilities could possibly be extended by the context. We have this to some extent right now with the ability to have a base composite and then subclass it, and then the subclass is instantiated whenever the base is requested. This is a crude version of the above, but the idea is the same. It's an interesting topic, and very fundamental, and it's gonna take some time to figure out exactly what is the best way to do these things. But progress is quick these days, given that "internet-time" is fairly condensed :-) /Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
