Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (nike.apache.org: domain of akarasulu@gmail.com designates
 209.85.161.50 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:content-type;
        b=I7mrY5KroZ5+Ugy7fZ4iTOgqdgMjAYTvtG/Wxd990xxk7ZXLqW8FKg2eIZo/bD0Qr7
         xYu9OWXSVLxUetsSe+N4w5AqN+H0rfXInMl8ForhL/SfIWOsDPvDVlFMIT8VTHmMXXsn
         yy+T/i761RH4lDYn3R7YJdT96+fifHd4ZAXh4=
MIME-Version: 1.0
Sender: akarasulu@gmail.com
In-Reply-To: <4BEFC02A.2070906@apache.org>
References: <4BEE633D.6020906@otego.com> <4BEE8756.5010403@gmail.com>
	 <4BEFC02A.2070906@apache.org>
Date: Sun, 16 May 2010 13:14:21 +0300
Message-ID: <AANLkTimx2zHE-ENJt6Od1FHu92pDriBFC8vBlZZ_UBra@mail.gmail.com>
Subject: Re: Mutable Objects
From: Alex Karasulu <akarasulu@apache.org>
To: Apache Directory Developers List <dev@directory.apache.org>,
 felixk@apache.org
Content-Type: multipart/alternative; boundary=001636458ec03820e60486b35f3c

--001636458ec03820e60486b35f3c
Content-Type: text/plain; charset=ISO-8859-1

On Sun, May 16, 2010 at 12:51 PM, Felix Knecht <felixk@apache.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> >> I suggest to clone such data and return the clone instead.
> >>
> >> WDYT?
> >>
> > This is not so simple. For instance, in the Value class, we returns the
> > direct internal object for performance reasons. It should be checked
> > case by case.
>
> I can agree the performance reasons. OTOH it's a 'public' class which
> may be used by other (third party) projects as well. For these projects
> we will need to have either a big warning in the javadocs or to
> implement it in a save way.
>
>
You're 100% right about that. We have to take precautions to make sure users
of the API do not shoot themselves in the foot. Each case needs to be
analyzed and changes to make some mutable structures immutable must be put
into our roadmap.

Felix this might be something that might help as an exercise for you to get
to know the internals of the server much better. Right now you're of course
invaluable to us in the way you've picked up various tasks.  However you
might find it extremely pleasurable to start tinkering with the more meaty
issues of the server. We have several very interesting problems and
rewarding potential solutions in this architecture. In addition, knowing
your insight and strict approach to following conventions, we would always
love to hear your suggestions on these matters as well.

Regards,
-- 
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
To set up a meeting with me: http://tungle.me/AlexKarasulu

--001636458ec03820e60486b35f3c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Sun, May 16, 2010 at 12:51 PM, Felix =
Knecht <span dir=3D"ltr">&lt;<a href=3D"mailto:felixk@apache.org">felixk@ap=
ache.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
</div><div class=3D"im">&gt;&gt; I suggest to clone such data and return th=
e clone instead.<br>
&gt;&gt;<br>
&gt;&gt; WDYT?<br>
&gt;&gt;<br>
&gt; This is not so simple. For instance, in the Value class, we returns th=
e<br>
&gt; direct internal object for performance reasons. It should be checked<b=
r>
&gt; case by case.<br>
<br>
</div>I can agree the performance reasons. OTOH it&#39;s a &#39;public&#39;=
 class which<br>
may be used by other (third party) projects as well. For these projects<br>
we will need to have either a big warning in the javadocs or to<br>
implement it in a save way.<br>
<div class=3D"im"><br></div></blockquote><div><br></div><div>You&#39;re 100=
% right about that. We have to take precautions to make sure users of the A=
PI do not shoot themselves in the foot. Each case needs to be analyzed and =
changes to make some mutable structures immutable must be put into our road=
map.</div>
<div><br></div><div>Felix this might be something that might help as an exe=
rcise for you to get to know the internals of the server much better. Right=
 now you&#39;re of course invaluable to us in the way you&#39;ve picked up =
various tasks. =A0However you might find it extremely pleasurable to start =
tinkering with the more meaty issues of the server. We have several very in=
teresting problems and rewarding potential solutions in this architecture. =
In addition, knowing your insight and strict approach to following conventi=
ons, we would always love to hear your suggestions on these matters as well=
.</div>
<div><br></div><div>Regards,</div><div>--=A0</div></div>Alex Karasulu<br>My=
 Blog :: <a href=3D"http://www.jroller.com/akarasulu/">http://www.jroller.c=
om/akarasulu/</a><br>Apache Directory Server :: <a href=3D"http://directory=
.apache.org">http://directory.apache.org</a><br>
Apache MINA :: <a href=3D"http://mina.apache.org">http://mina.apache.org</a=
><br>To set up a meeting with me: <a href=3D"http://tungle.me/AlexKarasulu"=
>http://tungle.me/AlexKarasulu</a><br>

--001636458ec03820e60486b35f3c--