> From: Stephen McConnell [mailto:[EMAIL PROTECTED]] > >>> The container must supply an implementation for all methods > >>> in the interface. This may be done via a dynamic proxy > >>> that routes calls to appropriate handlers or by any > >>> other method. > >>> > >>> > >>suggestion: remove the above sentence. > >> > >> > > > >I want to specify that this is container-specific. Unless this is > >specified, we get into abiguity: > > > >1. It is container-specific. > > > >2. It isn't, but the contracts are somewhere else. > > > > > > I agree with Leo Simon;s suggestion to remove the last > paragraph above.
Changing it to: "The container must supply an implementation for all methods in the interface. The method of supplying the implementation is container-specific." > This does not conflict with the statement that implementation is > container specific (which it is). The paragraph in question is > basically nothing more that a note concerning technical > implementation > which is really not part of the context contract. However, > it could be > included in the package documentation as a implementation note. Yes, that seems sensible. > >>> The set of methods that a container must > >>> support is defined by the standard context interfaces in > >>> Framework (currently none). > >>> > >>> > >>"a" container or "any" container? Regardless of the answer, > >>if there are no standard context interfaces I'd say there > >>should not be a reference to them either. So again, I suggest > >>removing that sentence. > >> > >> > > > >As above, I want it explicitly noted that there are none. > The absence > >of a statement to that effect can mean: > > > >1. That there aren't any. > > > >2. That there are some, but we've just not decided to mention them > > here. > > > > > > This is somewhat ambigouse. We have already stated that if the > container is going to deploy a component it must do it in accordance > with the context contract - and the default for the context type is > org.apache.avalon.framework.context.Context unless otherwise > specificed. > The class Context has no entry declarations - as such it is already > defined. The existance of the above paragraph makes this less > clear. The intent was that while there are none now, there may be some in the future, but OK - since everything is optional (the note at the very top makes that clear), it should follow that a container need not provide any methods. Cutting that. > > > > > >>>2. The second parameter is a set of entries accessible via the > >>> Context.get() method and their types. The class/interface T > >>> above may also have associated metadata that specifies entries, > >>> in which case these entries must be supplied by the container > >>> in addition to any entries the component itself requires. > >>> Each entry requirement must specify the canonical key name, may > >>> specify an alias for the canonical key and must specify the > >>> expected type of the value. > >>> > >>> > >>suggestion: change the above paragraph to > >>"2. The second part of the context contract defines the set > >>of entries the component can access via the Context.get() > >>method, where an entry consists of the key passed to get() > >>and the expected return type (ie the class or interface). > >>Optionally, an alias for the key name can be specified. The > >>contract associated with a particular entry is defined in the > >>container documentation. > >> > >> NOTE: It is our intend to specify common context entries and > >>associated > >> contracts as part of the framework documentation. This step > >> have not been taken yet." > >> > >> > >> > > > >"2. The second part of the context contract defines the set > >of entries the component can access via the Context.get() > >method, where an entry consists of the key passed to get() > >and the expected return type (ie the class or interface). > >Optionally, an alias for the key name can be specified. The > >contract associated with a particular entry is defined in the > >container documentation. > > > >The class/interface T > >above may also have associated metadata that specifies entries, > >in which case these entries must be supplied by the container > >in addition to any entries the component itself requires. > > > >NOTE: It is our intend to specify common context entries and > > associated > > contracts as part of the framework documentation. This step > > have not been taken yet." > > > >Common metainfo/data is about to be introduced. I see no > reason not to > >include it here. > > > > > I think we can address the concern of referencing meta while > its undefined by including a reference to the Meta > Specification on the Context javadoc that simply points to > the a section in the context package documentation. > > If we are going to mention meta then the description should > be updated to replace meta-data with meta-info. Here is an > example within the appropriate package summary link. > > The context interface T above may also have associated meta-info > that specifies entries, in which case these entries must be > supplied > by the container in addition to any entries the component itself > requires. Refer <a href="package-summary.html#meta">Context > Meta-Info Specification.</a> > > > The package documentation would contain the following: > > <body> > <a name="meta"/> > <h3>Meta Specification</h3> > <p> > Specification of meta-information relating to context and > context enties > is currently under discussion. > </p> > <h3>Implementation Notes</h3> > <p> > <!-- stick stuff here concerning container implementation > approaches --> > </p> > </body> Yep. Updating... (Please wait.) /LS -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
