Re: [Avalon4:PROPOSAL] Context Consensus

Noel J. Bergman wrote:
> Darrell:
> 
> I think that your points are valid, but that Avalon 4 is a "lost cause".  To
> quote Leo (and Berin appeared to say something similar), "most people do
> agree that there are better and more scalable ways to treat a context
> (although we don't agree on just what those ways are), but that the current
> usage pattern in Phoenix must be accomodated [in Avalon 4.]"  The last part
> being added by me.
> 
> It just doesn't make sense to change Avalon 4; we'll have to live with it
> for the time being, and encourage change for AV5, where I think that the
> issues you're raising should be championed.

I agree.

> Berin:
> 
>>As impacting Framework 5+, I would like to see a flexible context
>>that has very strong contracts--i.e. if you want a BlockContext,
>>you get one with no casting, if you want a ServletContext same thing.
> 
> If there is such a solution, I'm for it, too.  Do you have a suggestion that
> is BOTH strongly typed AND extensible?
> 
> The reason I have advocated passing the return class as a parameter of the
> lookup/get call, e.g., T t = (T) myContext.get(myKey, T.class) is that the
> context can verify the type of object that the caller is expecting.  If we
> added a suitable throws clause to that get method signature, we force the
> caller to prepare for the exception.

Personally, I don't like castings, and anything that can make it less 
"scary" I like. Hence I think your idea is interesting.
I like using the service classname to ask for a service to the 
servicemanager, but some like opaque keys. Hence the above example can 
be applied there too.

>>Although there is a considerable argument for a unified namespace
>>per component for both services and other data items.
> 
> Do you meant "considerable" in terms of volume or validity?  :-)  Regardless
> of volume (and I am currently in the composite namespace camp), I am
> interested in valid, maintainable, effective software.

-- 
Nicola Ken Barozzi                   [email protected]
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------