directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
Subject Re: [CONSTANTS] Changing AT and OC
Date Thu, 19 Apr 2007 17:24:40 GMT
Hi Ole,

On 4/19/07, Ole Ersoy <> wrote:
> Hey Alex,
> You do have auto complete you know :-)

Yeah but sometimes we edit files with vi too.  I'm not a proponent
IDE dependence.  I think IDE's dumb down developer skills and sometimes
auto completion causes errors too because people are less careful.

The original idea here was to minimize the
> learning curve for future contributors and
> code reviewers.

I understand that but if you cannot figure out that _AT, and _OC in a
XyzSchemaConstants file is shorthand for ATTRIBUTE_TYPE and
OBJECT_CLASS then you should not be editing these files.  Futhermore
they are simple suffix qualifiers that hint to users of these constants
about the nature of the constant.  Let me explain this exactly.

In these schema files you have the String constants for schema elements
like the ou attribute and the inetOrgPerson objectClass.  Besides
and objectClasses there will be other schema entity constants for things
matchingRules, dITStructureRules, syntaxes, etc.  These will have a suffix
abbreviation as well with the present schema like _MR instead of
_MATCHING_RULE.  I know about this because I've been doing this for years
(5 on ADS to be exact) and can foresee the explosion in the size of constant

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.

This is a valid suggestion and please even though I disagree with this which
is mostly a matter of opinion with subtle yet inconsequential impacts.

I just see the need for the convention because (respectfully) I have a far
greater understanding of this code and can foresee the problems that will

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.

Do you really doubt that I understand this fundamental concept which is
learned in your first intro to C/Java/whatever class?  Man I could not get
this far without applying simple engineering principals even though I
admittedly have failed to do so in certain cases.

SNIP ...

> There are so many abbreviations in LDAP, like
> ou, cn, sn....that when more get added the cognitive
> load is pretty significant for beginners.

Right this is certainly true.  But you should grok some of these fundamental
concepts before you decide to lecture us what conventions to use for our
names.  This is really a bike shed argument.  However you might want to stop
and listen to the reasons of a seasoned member of the team.  You did not
even consider my reasons based on the need for this convention to support
even longer names for things like _DIT_CONTENT_RULES etc.  You just cite
that you do not know what these are.

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.

Well that's because you lack the LDAP background and that's OK.  Just ask us
why and by all means challenge the norm but please respect us by listening
and trying to understanding our responses to you.

Several times we have said the same thing over and over again to you about
other topics while you ask your questions.  However I got the distinct
feeling that you're more focused on formulating your next response rather
than absorbing the information we are trying to impart to you in response to
your question.

Man there are only so many thoughts you can have in a day.  Ones mental
wattage exerted over the course of the day is finite.  I don't want to waste
it recapitulating things or arguing rather than sharing via a discourse to
exchange ideas to find the best outcome.

I think ApacheDS will be more popular for contributors
> when the code base is as simple as possible to work with.

That's a never ending battle.  Writing and LDAP/Kerberos server is not a
simple task and part of the art is in reducing this complexity I agree.
However this constant naming issues or convention is not that difficult to
grok especially if you gain some cursory understanding about the
fundamentals of LDAP.  It will become second nature to anyone after that.

So I'm not sure what STRUCTURE_RULE and MATCHING_RULE are
> right now, but I like STRUCTURE_RULE and MATCHING_RULE.

Right exactly so don't push the point on the convention until you do gain
this understand then we can discuss it.  Further get to a point where you
use these constants heavily so you can see the amount of space they consume
when completely spelled out.

It's very easy to understand.  Simplicity is free :-)

Nothing is free :-)


> 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* <
> > <>> wrote:
> >
> >     Just as suggested by pam, AT stand for ATTRIBUTE_TYPE, not ATTRIBUTE
> >
> >
> >     On 4/19/07, *Emmanuel Lecharny* <
> >     <>> 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
> > <>
> >
> >

View raw message