Quoting Rickard Öberg <[email protected]>:
Oh, I see. Well, the concern for method-constraints is mostly an implementation detail. Also, in a sense it doesn't compute to talk about "first" and "last", since they are "around concerns" in AOP-lingo. Both the method-constraints and return-value constraint concerns would be at the "top" of the invocation chain, if bottom=mixin. So both first AND last, in a sense.
Hmm true. However, constraints differ in that case a little from concerns, as they don't have .next field, right? So they don't "descend" deeper as concerns, but rather return from method. But yeah, on a high-level abstraction, they are both on top of the invocation stack.
This one is easy: if the priority is defined ON the concern, there can be only one!
OK. And if priority is defined somewhere elsewhere, the runtime will use some logic to decide the order when assembling application?
Interesting side-question: would that order be modifiable in runtime then?
Yeah, that's always the risk. One could also define neutral priority to be zero, and then higher is more to the top. Then you could always just put in a larger number to push it more to the top, and a negative value to make it run just before/after the mixin.
Yeah, that sounds like it could work out.
Good point. I'm not sure. I'm just looking at what options we have, at all. Right now we use the declaration order, but that is not really enough, since they can be declared in many places for any given composite method (a base composite, the actual composite type, mixin type, on the mixin class).
Yeah, declaration order is not enough for advanced needs. Also, this whole thing gets trickier when it is needed to decide, who and with what logic can control the order of concerns to execute: the implementator of concerns, the assembler of application, or someone whoever uses the whole thing? The last case is hardest to define rules and to implement, as it is superset of previous options. However, it is also most customizable / adjustable.
The list of methods to check can be cached, so there's no difference in performance. At some point there would have to be an isValid(composite,method) call that actually does the check, that's for sure.
Totally forgot about caching, hehe. Not sure how 'clean' or 'qi4j'stic way that is, but that's the first one i could think of to your specific case.
_______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
