> From: Peter Donald [mailto:[EMAIL PROTECTED]] > > On Wed, 10 Jul 2002 19:55, Carsten Ziegeler wrote: > > Peter Donald wrote: > > > > Why do you want to aquire the store even if it is not used? > > > > > > Basically to avoid warnings in a container I am working on. ie If > > > you declare dependencies (even if they are optional dependencies) > > > and the container provides you component but you dont use it then > > > the container will wanr you > > > saying something like > > > > > > "You have misdeclared a dependency on X as it was never used." > > > > > > or similar. > > > > Hmmm, I'm not sure if this is a good feature - because an optional > > dependency means it's - well - optional. And I see two use cases > > their: > > a) The optional component is only used if it is available > > thats the usecase I had in mind.
ServiceManager.hasService() Is supposed to be the low cost way of providing the functionality. > > b) The optional component is used only in some circumstances > > That is the usecase that I originally liked but Berin jumped > on me back in ye > old days for it. Then we both jumped on Fede (one of the > original avalon > developers). It may have been a misunderstanding or something like that. We all have grown as developers since then. > Whats everyone else think. Should optional dependencies be "optional" > depending on the presence of some attribute (be it config variable or > something). > > Or should it be the assemblers decision, ie If they provide > the component then > it is used else it is not. Any optional dependancy is just that, "optional". As such, the component should be able to handle the absence of that component. In the case of the variable/flag/attribute dependency, you still need to check if it is available. If your configuration says that you should use the store, check to see if your container has it. The component declared it as an optional dependancy, so if it doesn't exist it doesn't exist. In that case the "useStore" attribute is more a way to override the default behavior. We can prevent its use even if it exists, or we can say it is ok to use when it does exist. I could be wrong, but that is my understanding of it. I think it would be more work than really necessary to make the container aware of the content for the configuration information for the component to determine if a component is optional or not. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
