On 2010-01-18 16.32, Stanislav Muhametsin wrote:
Well, if you think of method-constraints as read-only concerns, then
these 'concerns' are always executed first. Order between
method-constraints shouldn't matter, as they can not change state nor
much else.
And with return-value constraints, they could be again like read-only
concerns, but always executed last prior to side-effects.
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.
I thought about something like that too. But where would it be possible
to specify order, and what to do if two different priorities are given
for one concern?
This one is easy: if the priority is defined ON the concern, there can
be only one!
And what if we want some concern to be ABSOLUTELY first
one to be executed, and there are multiple concerns defined with
priority 1?
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.
I'm sure that kind of logic is implementable, the question is, would it
be easy for developers to use and understand it?
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).
I'm sure that validMethods(composite) method could be done by
reflection, traversing through inheritance hierarchy upwards and
invoking isOperationValid(...) for each method. Would be quite damn slow
though, hehe. Or maybe just invoke isOperationValid(...) for each
specifically-tagged method of composite? The tag could be subclass of
one general tag-class, so the method would know to separate it from
other non-related tags.
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.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
