Re: Exceptions (was: RE: [Avalon4:PROPOSAL] Context Consensus)

Noel J. Bergman wrote:

>>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.
>

This is not adding anything that we can't already do i A4.1 + container.

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