directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: [CONSTANTS] Changing AT and OC
Date Thu, 19 Apr 2007 16:00:14 GMT
I don't care that much if its

public static final String AT = "AT";
or
public static final String ATTRIBUTE_TYPE = "AT";

(I do prefer the longer string, its much clearer for me, a beginner)

but I think using constants is essential.

thanks
david jencks

On Apr 19, 2007, at 8:47 AM, Ole Ersoy wrote:

> Hey Alex,
>
> You do have auto complete you know :-)
>
> The original idea here was to minimize the
> learning curve for future contributors and
> code reviewers.
>
> In that spirit I personally prefer to eliminate
> all abbreviations, with exceptions for
> special cases like where common terminology
> is used like DIT, or OU.
>
> Also, the purpose of using constants is to
> ensure that the constant can be changed
> in one place only, and then be automatically
> updated in all other places.
>
> So if we change "m-oid" to "mOid", we only
> have to do it in one place, and all of the code
> is updated.
>
> There are so many abbreviations in LDAP, like
> ou, cn, sn....that when more get added the cognitive
> load is pretty significant for beginners.
>
> I can only say for myself, and my nut is pretty small,
> but I had to go back and look up what each constant was
> a lot, because of the abbreviations.
>
> I think ApacheDS will be more popular for contributors
> when the code base is as simple as possible to work with.
>
> So I'm not sure what STRUCTURE_RULE and MATCHING_RULE are
> right now, but I like STRUCTURE_RULE and MATCHING_RULE.
>
> It's very easy to understand.  Simplicity is free :-)
>
> Cheers,
> - Ole
>
>
>
>
>
>
>
>
> Alex Karasulu wrote:
>> -1
>> I'm against this guys.  These contstants are getting way too  
>> long.  Typing them out is more of a hassle than just using the  
>> darn String for it.  Like OU_AT will now be OU_ATTRIBUTE_TYPE.    
>> The convention for AT and OC are just fine.  Extrapolate this to  
>> MATCHING_RULE and DIT_STRUCTURE_RULE etc and the code text gets  
>> filled up with long constant names for 2-3 letter strings.  That  
>> defeats the purpose of using the constant in the first place.   
>> Just learn and stick with the convension.
>> Until we get significant familiarity by those new to the code base  
>> they should stop trying to alter our existing conventions without  
>> knowing the full impact.
>> Alex
>> On 4/19/07, *Emmanuel Lecharny* <elecharny@gmail.com  
>> <mailto:elecharny@gmail.com>> wrote:
>>     Just as suggested by pam, AT stand for ATTRIBUTE_TYPE, not  
>> ATTRIBUTE
>>     On 4/19/07, *Emmanuel Lecharny* < elecharny@gmail.com
>>     <mailto:elecharny@gmail.com>> wrote:
>>         Ole Ersoy a écrit :
>>         >  I went ahead and scanned the constants files.
>>         >
>>         >  If everyone is cool with it, I'll go ahead and
>>         >  update the interfaces so that:
>>         >
>>         >  AT > ATTRIBUTE
>>         >  OC > OBJECT_CLASS
>>         >
>>         >  and recommit.
>>         >
>>         >  Sound ok?
>>         Go for it, but before committing, run
>>         mvn -Dintegration test
>>         on the top level project.
>>         If the test (20 minutes) is ok, then commit.
>>         Emmanuel
>>     --     Regards,
>>     Cordialement,
>>     Emmanuel Lécharny
>>     www.iktek.com <http://www.iktek.com>


Mime
View raw message