Alex Karasulu wrote:
Hi Ole,
On 4/19/07, *Ole Ersoy* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> 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
_MATCHING_RULE.
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
done.
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
arguments.
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
necessary?
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!! :-)
Cheers,
Ole
