Mailing-List: contact api-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: api@directory.apache.org
Received-SPF: pass (athena.apache.org: domain of fanf42@gmail.com designates
 74.125.78.27 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:cc:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=CPmVaM2cvXDNPRaV+lW6nidPQHREb4KQSQ/Jx14oG/ys+9Tehq6b/eop2TumaHjxaI
         DBCkBkCl+yIEyp2PQN9hGZGAbjVNEb6s4Wx5dmKc7gmzFfIVubiJI6v3ty7l6gzXEmp+
         rhLeLq4LXZAGWWIH0zefsI0Xaz6Rig6smEL38=
Message-ID: <4B4F994A.80305@gmail.com>
Date: Thu, 14 Jan 2010 23:23:06 +0100
From: Francois <fanf42@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr;
 rv:1.9.1.5) Gecko/20091204 Lightning/1.0pre Thunderbird/3.0
MIME-Version: 1.0
CC: api@directory.apache.org
Subject: Re: [DN] Existing API review
References: <4B4C7948.3000503@gmail.com> <4B4DAD6E.4040204@sun.com>
 <4B4DB6A7.6080308@gmail.com> <4B4F88B0.50505@sun.com>
In-Reply-To: <4B4F88B0.50505@sun.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

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