Quoting Rickard Öberg <[email protected]>:
On 2010-01-18 15.55, Stanislav Muhametsin wrote:
I remember having similar situation in my project, where I wanted some
specific concern to be always last (or first? don't remember). At that
time, I would have been content with some way to specify order of
concerns right there at interface.
But maybe method-constraints are just the way for specifying which is
executed first?
How would that work? And with any method for defining first, what
happens if two concerns are defined as being "first"? This is one of
the trickier parts of concern ordering, as I see it.
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.
Another way to do it is to use something like priorities, and simply
sort concerns according to priorities. Most of the time you won't
care and set "3" (on a scale from 1-5), but if you want to have it
run early, then set it to 1. That might be a better way to deal with
it. If we do something like that it also opens up for being able to
declare concerns on the constraint, which would be nice.
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? And what if we want some concern to be
ABSOLUTELY first one to be executed, and there are multiple concerns
defined with priority 1?
I'm sure that kind of logic is implementable, the question is, would
it be easy for developers to use and understand it?
And return-value constraints for what is executed last
before side-effects?
Not sure what you mean here. Can you describe more?
Hopefully my explanation above about constraints being like read-only
concerns clarifies.
Regarding your problem - what about having method Boolean
isOperationValid(...), which would take Class<? extends Constraint<?,
?>> (or something like that) as parameter, and then instantiate the
constraint, run it and return result?
No, I'd prefer to have something like "Method[]
validMethods(composite)", i.e. I don't want to ask separately for
each method.
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.
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
