directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <ole.er...@gmail.com>
Subject Re: [CONSTANTS] Changing AT and OC
Date Thu, 19 Apr 2007 15:47:21 GMT
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