On 4/19/07, Ole Ersoy <email@example.com> wrote:
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
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 attributeTypes
and objectClasses there will be other schema entity constants for things like
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 identifiers.
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 result.
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.
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 constant
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:
> 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
> 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.
> On 4/19/07, *Emmanuel Lecharny* <firstname.lastname@example.org
> Just as suggested by pam, AT stand for ATTRIBUTE_TYPE, not ATTRIBUTE
> On 4/19/07, *Emmanuel Lecharny* < email@example.com
> <mailto:firstname.lastname@example.org>> 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 Lécharny
> www.iktek.com <http://www.iktek.com>