Quoting Rickard Öberg <[email protected]>:
On 2010-07-08 17.43, Stanislav Muhametsin wrote:
Actually, now that I'm thinking about it, it might get too confusing
between using class cast and getRole(...). At least at the start. Maybe
the class casting as getting a role could be dropped altogether in favor
of getRole(...) method, which could do all the checking? Would it be too
cumbersome or inefficient?
We had something like that in the beginning, but dropped it. What is
the usecase you're looking at for having this?
On a general scale, it would be command-query separation taken further
- that means having ImmutableQuery role interface which allows passing
something onto client code and having almost-near-to-absolute
confidence that the client code really won't be able to modify
anything (as long as nothing in ImmutableQuery itself won't be
modifying anything). Otherwise there wouldn't be much point in having
IQ-role at all - if client code could just cast it back into
"original" role and do whatever changes it likes.
On a specific scale, my project at the moment involves a fairly large
framework designed to be used in any software application integration.
The robustness and security requirements for the used interfaces and
interface design are extremely important, so I have used the
command-query-immutablequery (mututally uncastable) separation
throughout the code, to ensure giving the correct roles to correct
parts of code. Currently everything is implemented manually via
getXXXQ() and getXXXIQ() methods and @This injections - but having
getRole(...) method would really make things easier, and as an
additional benefit, instead of returning raw private mixins, actual
proxies would be returned.
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
