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: neutral (asf.osuosl.org: 212.27.42.27 is neither permitted nor
 denied by domain of elecharny@gmail.com)
Message-ID: <44FCB403.6050601@gmail.com>
Date: Tue, 05 Sep 2006 01:17:23 +0200
From: Emmanuel Lecharny <elecharny@gmail.com>
Reply-To: elecharny@iktek.com
User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923)
MIME-Version: 1.0
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: [ADS 2.0] Naming convention ... again !
References: <d45b08f00609040341g748b8692u9e8a8819f275506c@mail.gmail.com>
 <44FCAF8B.6020109@bellsouth.net>
In-Reply-To: <44FCAF8B.6020109@bellsouth.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


>>
>> Good idea. But then I'm a little bit annoyed by the name 
>> BindRequestImpl. So am I with the BindRequestDecorator which could 
>> have been AbstractBindRequestDecorator, as we have AbstractMessage, 
>> AbstractRequest, etc.
>
>
> heh ok I'm not helping :)

Well, I have been a little bit to far :) Let's add Abstract in front of 
*all* abstract class, it seems a reasonnable approahc.
I like to keep BindRequest as an concrete class, because this is what 
users want to manipulate. Call it common sense... But then we need an 
interface to solve the previous problem. I propose BindRequestOperation, 
which name does not suggest that it is a concrete class. (and it's 
coherent with the Ldap grammar, where requests and response are seen as 
Protocol Operations)

>
>> To be short :
>> Q1 : Should we add an 'I' in front on interface that are not 
>> obviously seen as interfaces (like BindRequest : renamed to 
>> IBindRequest) (I mean to avoid a collision between an interface name 
>> and a class name) ?
>
>
> Hmmm I've never like this style. -1.

I have used it, but IList sounds strange and IMap looks like the mail 
protocol to me :) So let's avoid M$ C# and Hungarian notations to close 
source :)

>
>> Q2 : Should we add an 'I' in front of *all* interfaces, breaking the 
>> JLS rules ? (so Message will be renamed to IMessage, even if it's 
>> obvious that Message cannot be a concrete class)
>
>
> Yeah -1 on that.

ok, definitively a -1, I think.

>
>> Q3 : Should we add 'Abstract' in front of abstract class ?
>
>
> +1

Ok, me too.

>
>> Q4 : if Q1 and Q2 is *NO !!!*, then which name should we use for 
>> class which implements interface : ConcreteBindRequest, 
>> BindRequestImpl ?
>
>
> Either is fine w/ me as long as we're consistent.  Concrete prefix is 
> not bad.  I kind of like the fact that it's what the GoF did in their 
> examples.

I think that classes which are not seen from an API could use Concrete 
in front of their interface name. However, I'm a little bit reluctant to 
use that notation for end users classes... As I said before, the API 
users want yo manupulate a BindRequest, not a concreteBindRequest, no ?

>
> Alex
>