I thought about this a lot at one point and was compelled to add it.  The reason being the ability to request a normalized version of the value without having to feed the attributeType into the normalize method.  Or the need to ask the attribute to normalize the value on the value's behalf since the attribute is what knows the attribute type and hence has access to the normalizers.  So this allows an attribute value to be normalized without requiring direct access to the attribute type by the caller. 

Also we are thinking about making some default implementations of various interfaces like Entry, and Attribute act as factories for the objects they contain.  This way a value "belongs" to some attributeType and attribute.  If you don't have a reference to the attributeType the only other way to have an argument free normalize() method on the value is to have a back reference to the attribute the value belongs to in the value.  From there the attributeType can be accessed and used to normalize without requiring the caller to provide additional arguments like a norrmalizer or an attributeType.

At a high level in my mind an attribute value is closely associated with an attributeType in terms of the way it is compared, returned and set rather than with a specific attribute of a specific entry.  This decoupling can be exploited in indices on specific attributeTypes which will contain the values of various entries.


On Dec 15, 2007 8:49 PM, Emmanuel Lecharny <elecharny@gmail.com> wrote:

while writing some tests for the DefaultServerAttribute class, I'm
wondering if it's such a good idea to store the AttributeType into each
value. This AT is already stored into the ServerAttribute instance,
where it is meaningful. I'm not sure that it's necessary in the value
classes : all thec checks will be done using the attribute as a
container for the values.

wdyt ?

cordialement, regards,
Emmanuel Lécharny