From: "Berin Loritsch" <[EMAIL PROTECTED]> > Then focus on an "extension" of the Class object (I know it is declared final, > so inheritance is out of the question), that has a set of "attributes". These > attributes mean different things to different people/contexts. Also, don't think > of attributes as a simple name=value pair. C# attributes have the concept of > parameters as well as the attribute itself. For example: > > /** > * @avalon:component > * @avalon:role=org.apache.excalibur.DataSourceComponent > * @avalon:creation-policy=singleton > * @test:multi-value=value1,value2,value3 > */ > > This would declare a class to have the "avalon:component" attribute, the > "avalon:role" attribute with the value set to "org.apache.excalibur.DataSourceComponent", > etc.
+1 > These attributes can be read from the IClass (BTW, I hate prefixed interfaces/etc.-- > interfaces should be your primary type, so if we have any idioms put it on the > implementing class). The name of the interface could be AClass, with the implementation as AClassImpl. Not sure if this is better though. IClass and AClass feels more 'right' (ie. normally I would agree with your no prefix comment Berin) Stephen > Attributes that are method specific would be put in the > javadoc for your method. In your case you want to know the type info for a DynaBean > return value: > > /** > * @dynabean:return=java.util.Date > */ > Object getDate(); > > You would want the "dynabean:return" attribute for the "getDate()" IMethod, or whatever > you call it. > > The Attribute approach is very simple, and is easy to use. Its meaning only gives > purpose based on the context. The "test:multi-value" attribute in the first example > would be used in a testing framework so that you can apply the same unit test for a > suite of methods/classes--and they don't even have to set up the same interface (the > Delegate stuff can take care of it). In fact using attributes is a great way to > *generate* JUnit tests automagically! > > > > >>Meta info that is useful to me is things like this: > >> > >>* Creation policy (pooled components, thread local components, singleton > >> components, etc.) > > > > Agreed. > > > > > >>* Required components (i.e. when one component requires a component of > >> another type) > > > > Could you provide more details on this one? > > In Avalon components can require other components to function. An example > would be the DatabaseReader from Cocoon. It reads information from a database, > but uses the org.apache.avalon.excalibur.DataSourceComponent to get the connection > from a pool. By declaring this dependency up front, the attributes for the class > would enable a container to ensure that an implementation of the required component > existed. If it did not, the container can post a failure notice immediately that > makes sense. > > > -- > > "They that give up essential liberty to obtain a little temporary safety > deserve neither liberty nor safety." > - Benjamin Franklin > > > -- > To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@;jakarta.apache.org> > For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org> > -- To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>
