On 2010-01-18 17.04, Stanislav Muhametsin wrote:
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.
Correct, I was talking about the Concern I used as an implementation of
the constraint check. That needs to be at the "top".
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?
Preferably the priority should only be set on the concern itself.
Interesting side-question: would that order be modifiable in runtime then?
Nope. That would be a nightmare I think...
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.
I would prefer if the concern implementor is the one that decides, but
the application assembler can certainly have other opinions. Not sure
how to handle that. To begin with setting priority on the concern itself
should be good enough.
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.
We have a couple more such caches. For example, when you look up a
builder given a class type that resolution is cached, as it never
changes. Look at all the *Finder classes in the runtime.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
