Berin Loritsch wrote:
Again, I am splitting this up into three threads. The first one is already
under way. Each thread represents a different level of concern.
In this thread, we are dealing with the context, logging, and configuration
meta tags. I personally do not have a strong oppinion against them. I can
see value for their existence. As the context and configuration aspects are
fairly Avalon specific, I don't mind them being in the Avalon namespace. I
do request that they be specified as *optional* meta information.
* Optional to implement?
That's fine - it just means that the container documents that fact that it does not provide support for the particular tag and includes at least some form of graceful failure if a component declares a unsupported constraint.
* Optional to recognize?
That would defeat the purpose of the specification. We would simply be regenerating another insufficient specification.
So what exactly do you mean by optional?
The logging attribute is more generic, but there is little point in defining a new namespace just for that concern.
Part of the reason why I am somewhat hesitant about them is because of the
cry for simplicity. PicoContainer, Fortress, ECM, and Phoenix (with the
exception of the configuration tag) all live quite happily without them.
How do container specific APIs, container specific context entries, and container specific casting constraints add to the simplicity of working with Avalon technologies? Is this not falling back into the AMTAGS V1 trap - the insufficient specification that won't deliver on its promise.
While they make certain things like dynamic assembly a workable reality,
These tags have nothing to do with dynamic assembly.
I wonder how many developers will agree that they *have* to use it.
A developer does not *have* to anything unless they need to express a constraint - such as a context entry with a key, castable to a particular class, or the assumption that a context object can be cast to another interface. Developers don't *have* do any of this - presuming they are happy with the concept of container lock-in.
I like validation, and I think we should provide hooks so that developers
interested in validation and verification of their system can let it take
place automatically. On the other hand, I don't think we should make it
a mandatory thing for those developers with very simple needs. I.e. it
helps reduce the complexity of writing components for those who don't want
that complexity.
I understand the "mandatory" thing you suggesting here. There is nothing mandatory for the developer. They have choice. The context where mandatory should be discussed is with respect to the responsibility of a container to recognize the full suite of tags. Developers simply get to leverage what makes sense in their environment.
I believe this is a reasonable request.
:-)
My second concern has to do with the implications on implementation. As
long as I can choose any method I like to validate the context entries or
configuration, all is well. I don't want to be forced into a contract
between context entry dependency declaration and context entry definition.
The AMTAGS should be strictly applied to making the component writer's
life easy.
What's your point? If a componet author states he wants a widget and he's going to ask for it using the key "widget" - then a container should either fulfill this request or fail gracefully. The contract we are talking about is container "recognition" - recognizing that you can or cannot fulfill the expectations that a component has on a container.
Steve.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
Sent via James running under Merlin as an NT service. http://avalon.apache.org/sandbox/merlin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
