On Mon, May 12, 2008 at 10:41 PM, Rickard Öberg <[EMAIL PROTECTED]> wrote:
> For example, let's say that a Module has registered CompositeA with > Module visibility and "CompositeA2 extends CompositeA" with Layer > visibility. If you then ask the Module for "find" CompositeA you will > want different things depending on who's asking: if the resolution is > coming from within the Module then it should return CompositeA, whereas > if the request is coming from outside, then CompositeA is not visible > but CompositeA2 is, so that should be returned as a valid type. For > "get" requests of CompositeA it should return CompositeA if it is > requested from within the Module, and null if it is requested from > outside of the Module, since "get" style requests should not try to take > extends into consideration. This is not what I think is smart (or I misunderstand you). I wanted to see a very simple semantic contract; get - "What Composites do you have?", i.e. return what is collected irregardless who is asking. find - "What Composites can you see?", i.e. all the above + what the visibility rules will also add. Having to figure out "who is calling" seems to be too much of a problem, whether that being a caller context or passing the caller... Doesn't sound right. My original point was that if there is a "get", then the "find" method will (at some point) simply use the "get" to build the visibility tree. The second item, which I think you are also discussing in the same breath is the "mapping" of types to Composites, but not sure, since you speak of subComposites which should be something else, and something I can't figure out right now. I think I need more info... Cheers Niclas _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
