Do you think we should make a Catalog an optional property of a Context? A lot of use cases would like to have a default spot to go find one, and you can always have private conventions about what other attribute keys might also point at other Catalogs.
If we are talking about the Context interface, it might be problematic, since it would seem that any property we define there would steal it from the application. So, they could not have a "context" attribute of their own, even if they were using context in, well, a different context =:)
But if by optional we mean a property on a base implementation, then that would seem all right. Worst case, they implement their own base. I like the loosely knit relationships between the three interfaces, but at some point implementations do need to start to nail things down for people.
Of course, once we do that, a question someone is going to ask sometime is "Why doesn't the Command just have a pointer to its Catalog?" I'm not convinced it would be a good idea, but it's something we should ask and answer.
Another popular question will be, "Why isn't the Context itself a Map?"
In my own base class, I needed to make it a Map (through composition - the Map methods just call back to getAttributes) so it could mesh with other parts of the application. It's going to be a FAQ, so we might want to deal with it now.
I think the answer is going to be extensibility, but we might consider an optional implementation that provides a Map interface for people to use.
On a related subject, how do we feel about the BaseContext2 class that allows property fields to be stored in the attribute Map? I have mixed feelings about the implementation, since it bends encapsulation, but I *really* like the idea of keeping all my fields and attributes together.
-Ted.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
