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 recognize?
That would defeat the purpose of the specification. We would simply be regenerating another insufficient specification.
It would still be sufficient for some--just not everyone. Seriously though, the difference between recognition and implementation is somewhat blurred. What is the true difference between recognizing information to ignore it later and simply not recognizing it at all? Its just semantics.
So what exactly do you mean by optional?
I mean optional to define. The AMTAGS proposal is about the component writer's declarations to the container. What the container does with it is really up to the container (to a point). IOW, I just don't want to force users to declare an @avalon.context.entry for each value they use if it isn't important to them.
For instance, I am coming from a Fortress/Phoenix world where these tags don't currently exist. If I now have to go back and add the meta info for all the context entries just so that they can work again, then I have a problem. If my existing functional components don't have to be altered then I am happy.
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.
Nothing. I am just starting to chew on how to do the same thing without developer declared meta data. I don't even have a vague idea yet, but there has to be a way to make things work without having to half think about it.
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.
Of course if there are standard context entries, then they don't *have* to use it, and they won't be locked in to a container.
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'm glad.
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.
Right. As things are defined right now, there is no problem.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
