directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <>
Subject Re: [CONSTANTS] Changing AT and OC
Date Thu, 19 Apr 2007 18:25:54 GMT

Alex Karasulu wrote:
> 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.

Well - I could debate that - But I'll let you have it :-)

>     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.

This one I'll debate.  But I'm basically just repeating stuff though.
Having stuff spelled out just makes it simpler to get rolling.  I know
for a fact that I would be much more productive if they had been spelled
out initially.

>  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 

AHA! So MR means matching rule.  I was wondering what that was.
This underlines my point I think.  When I start looking at some
new code, the more abbreviations just mean more cognitive load.
The brain naturally wonders, what's that...using precious
processing cycles that could be used to get something

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 think the impact of having the code be easier to read is that more
people will want to work with it.  It's very well done in general, but
abbreviations like MR, AT, etc. does take more time to get used to
than if they are written out.

> 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.

Respectfully, are you saying that there will be a problem if
MATCHING_RULE is in the string constant, instead of MR?

>     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. 

No doubt.  I definitely think you know that.  Just wanted to make
sure the rationale is clear for everyone else reading the thread.

> 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 constant
> names.  

Alex - We did grok.  Emmanuel Grokked and agreed initially.  Also this 
was just a quick suggestion.  I think the word "Lecture" comes from the 
fact that I pointed out some simple things.  I do that when I think
something is not clear.  I think people understand it, but I'd rather
be as clear as possible, when I think there is an opportunity for more
clarity :-)

> This is really a bike shed argument.  

I really think we should just avoid trivializing and characterizing

> 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'm sorry - which reasons did I not consider?

>     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. 

Alex, all I can tell you is that I do read very closely, and try to take 
things apart and understand them carefully.  That's one of the reasons
I like email so much, is because it lets me read and analyze, before
commenting. Plus everything is there for the record.

> 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 agree - I like to focus on facts, concepts, and understanding.

>     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.  

Respectfully Alex, here you are saying that a somewhat abstract thing.
Lets just keep it simple.  All this is about is whether
OC, MR, etc. are simpler to understand for beginners than their
corresponding abbreviations.  Yes, someone can learn them, just like
we learn vi commands, but it takes time.  So lets keep the focus
around the pros and cons of doing something like this.

> 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.  

Wait a minute.  Are you saying that it's necessary to understand and 
abbreviation before it possible to discuss whether the abbreviation is 

Some of the abbreviations, are really LDAP abbreviations, like DIT and 
OU, etc.  Those I think are fine to keep as abbreviations, and I said 
so.  We're talking about about "Our" abbreviations here, and I'm saying
that some of these things would make the code base simpler to work with
if they were spelled out.  I agree that we should leave DIT, OU, etc.
where it's common LDAP terminology the way it is.

> 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.

I have lots of constants like that all over my code.  I'm the one who 
suggested the use of the constants.  It's very easy to understand
that longer constant names increase the the amount of space consumed.

And maybe there is a real cost to that?

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

OK - I'm going to debate that!!  :-)


View raw message