[picocontainer-dev] Characteristics (naming) discussion

OK so am looking at it again.  First a correction its  
ComponentCharachteristics/Characterisations ( not Charachteristics/ 
Characterisations)

On Attributes ?  There's some overlap withe some prior art.  XML has  
attributes, and our use (if we were to switch to it) would be good  
there.  The second is C# its attributes are Java's annotations  
(though slightly more powerful).  Because of that, we should avoid.

On merging into Behaviors - I'm not so keen - There's already a  
Behavior (interface) AbstractBehavior (class) and Behaviors (class)  
like Collections or Arrays in java.util.  What Characteristics are is  
quite far removed from that.

What I'm thinking of is a step further on Guilherme's attributes  
thought -  Properties.  The clue is in ComponentCharachteristics  
class itself - it is primarily a properties sheet.  Thus

   ComponentCharachteristics should be ComponentProperties
   Characterizations could either remain so, or be PresetProperties  
or similar

 From the Mac's dictionary :- "an attribute, quality, or  
characteristic of something : the property of heat to expand metal at  
uniform rates."

Thoughts?

- Paul

On Jul 6, 2007, at 2:26 PM, Mauro Talevi wrote:

>
>
> On Fri, 6 Jul 2007 09:46:26 -0700, Paul Hammant <[email protected]>  
> wrote:
>> Yup, good thoughts. Will do later.
>>
>> Help me on Charachteristics/Characterisations class naming..
>>
>> Charachteristics  is an object for DPC that contains characteritics
>> to be processed during addComponent(..).
>> Characterisations is a list (a list of static classes) that contain
>> add characteristics to a DPC (temporarily or permanently).  The
>> include behaviors, as well as designating injection types. Later they
>> could include things like "names" for JMX:
>>
>>      pico.as(JMXNAME("Foo")).addComponent(Foo.class);
>>
>
> Here's my rationale:  it seems to me that there is a lot of overlap  
> between the concepts of Behaviours and Characteristics, even if not  
> the same object type.   The "behaviour" of a component is what we  
> are trying to model via the characteristic (eg CDI, SDI, CACHING,  
> etc).
>
> In primis, Characterisations is just a static collection of method  
> to create Characteristics.  So I would right off the bat merge the  
> two, ie add the static methods to the class which they are  
> instantiating.  I don't think that as a "dirty practice" - but I'm  
> happy to be argued down if someone objects for some reason.
>
> Secondly, I would rename Characterstics to Behaviours - which of  
> course is a different object from the Behaviour interface and its  
> impl. The best analogy I can find is the java.util.Collection/ 
> Collections:  one an interface, the other a utility class with  
> static access methods.
>
> Behaviour as a name seem morer intuitive that characteristic.
>
> Cheerse
>