Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@apache.org Received: (qmail 29600 invoked from network); 12 Dec 2002 05:43:59 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 12 Dec 2002 05:43:59 -0000 Received: (qmail 1101 invoked by uid 97); 12 Dec 2002 05:45:16 -0000 Delivered-To: qmlist-jakarta-archive-avalon-dev@jakarta.apache.org Received: (qmail 1065 invoked by uid 97); 12 Dec 2002 05:45:14 -0000 Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon Developers List" Reply-To: "Avalon Developers List" Delivered-To: mailing list avalon-dev@jakarta.apache.org Received: (qmail 1053 invoked by uid 98); 12 Dec 2002 05:45:13 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Message-ID: <3DF8223F.3000400@apache.org> Date: Thu, 12 Dec 2002 06:44:31 +0100 From: Stephen McConnell User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Avalon Developers List Subject: Re: Exceptions (was: RE: [Avalon4:PROPOSAL] Context Consensus) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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: 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:mcconnell@osm.net http://www.osm.net -- To unsubscribe, e-mail: For additional commands, e-mail: