Noel J. Bergman wrote:
This is not adding anything that we can't already do i A4.1 + container.I'm not disagreeing.All I'm saying is that there probably ought to be a best practice to avoid
the problem so long as this flawed interface survives.
The same logic applies to a new or revised context interface.
The AV5 approach shouldn't really have the problem to the same extent because the Context object passed shouldn't require casting. But this is actually a reason for why I had proposed Context.get(Key, Class), which would tell the container exactly what kind of interface I was expecting to receive.
If you decalre th following meta:
<type>
<context type="x.y.z.BlockContext">
<entry key="urn:avalon:work" type="java.io.File"/>
<context>
</type>
I (as spokesperson for Merlin) can gaurantee you that the object provided to you will be castable to you requested interface and that it will be supplid with the requested keys fully populated and that each key value will be castable to the requested interface.
Imagine that we have an avalon framework meta contract - and imagine that every single avalon container implements that meta contract. That means you don't need to worry, becuase the container will assure that what you get is what you want (irrespective of what actions you take at runtime). If you do additional defensive coding, its only because your intending to run your component in a non-compliant framework.
That's my view of the direction we should be heading towards with respect to the Avalon V Containment API.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
