RE: [Avalon4:PROPOSAL] Context Consensus

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.

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.

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

	--- Noel