Le 14/01/2010 22:12, Matthew Swift a écrit : Matthew, thanks for your answer, response inlined :
I understand very well why you think Attribute could be immutable. In fact, I went to great lengths to convert our Attribute API in OpenDS server so that it was immutable in order to be able to optimize for the common case (single valued attributes) and to avoid defensive copies. The result was a 4x performance improvement in the server (!). However, this did introduce some pain - any code in the server which tried to modify an attribute became more complex. For example, I had to implement an AttributeBuilder class to facilitate incremental construction of Attributes.
Well, some part may have been for simpler too. Appart from optimization and caching in particular, the other usual suspect is multi threading management where attributes are involved (I don't know what OpenDS is doing about it)
look at all those arrays with Javadoc warnings saying that you are not allowed to modify the content. Very suspect!).
:) I shot my eyes on them and said to myself they don't exist ;)
I thought about this long and hard for the OpenDS SDK and decided that a client API with an immutable Attribute would not be very easy to use. Many client apps will want to create and modify attributes and we should make it as easy as possible.
I'm not totally convinced about that, because I'm only a client user, and I do like immutable attribute :) But perhaps it's because I'm only working on Scala, and that collection are far more powerful and easier to deals with than in java - for example, creating a new attribute from the value of another filtered in some way and then transformed is a matter of one (not long) line - really, filter, map and flatMap are missing in Java.
In addition, I think that it is very likely that some users of the SDK (including the server itself) will need to have different types of Attribute - in other words, they'll need to sub-class Attribute (e.g. in order to create lazy decoded Attributes, virtual Attributes, copy on write, synchronized, etc). By implication any class which is non-final is not immutable since a sub-class could be implemented which breaks the contract (I realized that I had made this mistake in the server since our Attribute class is in fact an interface).
OK, I understand that. What I fear it is that if attribute are mutable in their interface, they will always be think about as that, and immutable attributes will come as a surprise with runtimeerror - it's what I dislike in the Java collection API approach: having mutation operator that just throws errors in place of simply not being here.
I agree that Entry DNs should not in general be modified, but I think preventing clients from doing this is a bit of an artificial constraint. There's no hard reason I can think of why you would want to prevent modification. In addition, if Entry is an interface (as it is in the OpenDS SDK) then, like Attribute, adapters can by provided which render some Entry operations unsupported. For example, you could have a Collections-like unmodifiableEntry method or even a unrenamableEntry in order to address the requirement above.
Perhaps... I still don't like very much the design pattern that make compilation ok for methods that we know will always throw "not supported" exception.
So... Well, I really tend to prefer immutable data structures as a client user, but I may be the only one in that case (and I don't thing there will be a lot of users of the API that would be on my side).
Goog evening, -- Francois ARMAND http://fanf42.blogspot.com
