Niclas Hedhman wrote: > 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.
So this will not consider any visibility flags? > find - "What Composites can you see?", i.e. all the above + what the > visibility rules will also add. Right, but to implement this it becomes useful to add "find Composites with this visibility level", since you can then do: module.findComposite(type,module); none found -> layer.findComposite(type,layer) -> module.findComposite(type,layer) none found -> layer.usedLayers.findComposite(type,application) -> module.findComposite(type,application) I.e. the methods that considers the visibility are an *implementation detail* of the module.findComposite(type) method, which is what is in the API. Same goes for service lookups etc. > 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. Yeah, there are two axis of lookup parameters: visibility and class hierarchies. when you do a "find" you need to know whether to just check for visibility or to include the class hierarchy of the requested type as well. My current thinking is that I will add methods to model/resolution/binding levels that does: model -> "get" resolution -> find, with visibility rules binding -> find, with class hierarchy rules E.g. if I have a "CompositeA extends CompositeB" with Layer visibility in a module: model.get will return CompositeA but not CompositeB resolution.find will return CompositeA from another module in the same layer but not CompositeB binding.find will return CompositeA and CompositeB from another module in the same layer if this is done correctly, then perhaps there is no need to include visibility in the find() method parameters, since it will be inferred depending on whether the call is to model,resolution or binding levels of it all. I have to try it out to see if it makes sense I think. /Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
