Quoting Niclas Hedhman <[email protected]>:
I have no strong GutFeeling(tm) either way on this.
But perhaps slightly more inclined towards;
* All declared concerns and side-effects are executed for public
methods regardless of where the call is originating from.
Seems to be easiest to explain that way.
That would be simplest and uniform way, yes. However, sometimes it
would be useful to provide the programmer with the clear way to bypass
the possibly performance-costly mixin invocation (in cases of
recursion / something else). One way to do this would be to make
private aliases of public methods, however this would work only for
mixins which implement all the methods of the interface(s).
I guess this is a little like C++ and memory handling. Qi4j could give
the programmer a powerful way to explicitly handle these scenarios,
however the programmer risks his or her application to work
incorrectly whenever he makes mistakes, just like with explicit memory
handling with C++. Or Qi4j could do the work behind the scenes in one
uniform way, and the (hopefully few) programmers which would want
things to work differently will need to introduce their own hacks for
it.
It's really hard for me to say which is the "better way". I used to
think that a uniform way of doing things behind the scenes was the
best way, and for some things it still is (things that can be truly
automated). However, I've had quite a lot of cases where this uniform
behaviour was certainly not something I want, and customizing /
changing it was pretty much impossible without throwing the whole
framework / whatever i was using away.
Regarding explanations, I think having explanation like the following
is almost equally simple (and sound) as the one Niclas provided.
* Declared concerns and side-effects are executed for public methods
IF AND ONLY IF the call originates through @This -injected variable.
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
