|
Home > Archive > Apache Directory Project > April 2007 > [CONSTANTS] Changing AT and OC
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
[CONSTANTS] Changing AT and OC
|
|
| Ole Ersoy 2007-04-19, 1:11 am |
| 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?
Cheers,
- Ole
| |
| Emmanuel Lecharny 2007-04-19, 7:11 am |
| 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
| |
| Emmanuel Lecharny 2007-04-19, 7:11 am |
| Just as suggested by pam, AT stand for ATTRIBUTE_TYPE, not ATTRIBUTE
On 4/19/07, Emmanuel Lecharny <elecharny-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> Ole Ersoy a écrit :
>
>
> 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
| |
| Alex Karasulu 2007-04-19, 1:11 pm |
| -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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> Just as suggested by pam, AT stand for ATTRIBUTE_TYPE, not ATTRIBUTE
>
> On 4/19/07, Emmanuel Lecharny <elecharny-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > wrote:
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
| |
| Ole Ersoy 2007-04-19, 1:11 pm |
| OK - Cool - I'll make it ATTRIBUTE_TYPE.
Emmanuel Lecharny wrote:
> Just as suggested by pam, AT stand for ATTRIBUTE_TYPE, not ATTRIBUTE
>
> On 4/19/07, *Emmanuel Lecharny* <elecharny-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> <mailto:elecharny-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>> wrote:
>
> Ole Ersoy a écrit :
>
>
> 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>
| |
| Ole Ersoy 2007-04-19, 1:11 pm |
| 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> <mailto:elecharny-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>> wrote:
>
> Just as suggested by pam, AT stand for ATTRIBUTE_TYPE, not ATTRIBUTE
>
>
> On 4/19/07, *Emmanuel Lecharny* < elecharny-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> <mailto:elecharny-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>> wrote:
>
> Ole Ersoy a écrit :
>
>
> 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>
>
>
| |
| David Jencks 2007-04-19, 1:11 pm |
| I don't care that much if its
public static final String AT =3D "AT";
or
public static final String ATTRIBUTE_TYPE =3D "AT";
(I do prefer the longer string, its much clearer for me, a beginner)
but I think using constants is essential.
thanks
david jencks
On Apr 19, 2007, at 8:47 AM, Ole Ersoy wrote:
[vbcol=seagreen]
> 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:
[vbcol=seagreen]
| |
| Emmanuel Lecharny 2007-04-19, 1:11 pm |
| Ole,
Alex don't like ATTRIBUTE_TYPE and OBJECT_CLASS prostfix, and I understand
his rationnal.
That means : don't commit this change.
PS. There are two unwritten rules you should always think about before
proposing a change :
- if it's not broken, don't fix it
- respect existing conventions even if you don't like them
I should have asked Alex before telling you to move on. My bad.
Emmanuel
On 4/19/07, Ole Ersoy <ole.ersoy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> OK - Cool - I'll make it ATTRIBUTE_TYPE.
>
> Emmanuel Lecharny wrote:
>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
| |
| Emmanuel Lecharny 2007-04-19, 1:11 pm |
| David,
On 4/19/07, David Jencks <david_jencks-/E1597aS9LQAvxtiuMwx3w@public.gmane.org> wrote:
>
> I don't care that much if its
>
> public static final String AT = "AT";
> or
> public static final String ATTRIBUTE_TYPE = "AT";
>
> (I do prefer the longer string, its much clearer for me, a beginner)
Sure. The problem is that we have many of those guys all around the server,
and if you use long name, you will get constants like :
public static final String STRUCTURAL_OBJECT_CLASS_ATTRIBUTE_TYPE_O
ID = "
2.5.21.9";
when we already have :
public static final String STRUCTURAL_OBJECT_CLASS_AT_OID = "2.5.21.9";
AT and OC should be clarified once, then as they are used everywhere, it
should be easy to remember what they mean.
but I think using constants is essential.
Absolutly. And we are slowly migrating all of them in a specific subproject
(shared-ldap-constants)
thanks
> david jencks
>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
| |
| Emmanuel Lecharny 2007-04-19, 1:11 pm |
| Ole,
On 4/19/07, Ole Ersoy <ole.ersoy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> Hey Alex,
>
> You do have auto complete you know :-)
This is not the problem.
The original idea here was to minimize the
> learning curve for future contributors and
> code reviewers.
Using AT and OC should not be a real problem. If you are down to the code
where you are using those abbreviations, then it means you already have a
certain level of knowledge about what is what in Ldap.
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.
You personal preference are ok, but we are in a community, so we have to
accept this community habits and conventions. I don't think that all are ok,
and all don't fit my vision of what should be 'beautiful code', but at least
they are pretty close. You can still suggest something different, but
sometime people might disagree. However, this code base is now 3 years old
(and you can add 2 more years before it moved to apache), and we won't break
the commonly accepted conventions easily.
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.
Ole, we are aware of that. I think we all have a serious background in
coding...
>
> There are so many abbreviations in LDAP, like
> ou, cn, sn....that when more get added the cognitive
> load is pretty significant for beginners.
On the opposite, Ldap is not simple. RFCs which describe LDAp are huge :
probably around 500 pages if you gather all of them. Don't excpect LDAP to
be simple. The coginitive load *is* significant, even for experimented
players...
<snip>
> I think ApacheDS will be more popular for contributors
> when the code base is as simple as possible to work with.
The code base is *huge* (more than 260 KSLOC :
http://www.ohloh.net/projects/4872, and more than 450 KLOC if you include
comments and blank lines). Don't expect new comers will have easy time
getting into it, it would be a lie to say that. However, I personally think
that the code base is pretty clean and neat, even if we do have some places
where it's not pure beauty...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
| |
| Ole Ersoy 2007-04-19, 1:11 pm |
|
SNIP
> PS. There are two unwritten rules you should always think about before
> proposing a change :
> - if it's not broken, don't fix it
> - respect existing conventions even if you don't like them
Emmanuel, initially you liked the suggested change.
David seems to like it as well. The reason
I'm mentioning this is above you are saying
> - respect existing conventions even if you don't like them
What does that mean exactly (In terms of the current context)?
Also, if it's not broken don't fix is VERY ambiguous.
Lets just stick to facts and concepts ok? Communicate clearly
and simply with examples if necessary.
You said do it. Alex said don't do it.
This is a democracy. We all have to agree before
something is done. That means we have to discuss
it and make sure everyone has clearly understood each other's
rationale.
>
> I should have asked Alex before telling you to move on. My bad.
>
True.
Cheers,
Ole
| |
| Emmanuel Lecharny 2007-04-19, 1:11 pm |
| On 4/19/07, Ole Ersoy <ole.ersoy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>
> SNIP
>
>
> Emmanuel, initially you liked the suggested change.
> David seems to like it as well. The reason
> I'm mentioning this is above you are saying
I said, 'do it', then alex said don't. And he explained why. I respect Alex
rationals, and I may have said 'do' a little bit too quickly. My bad.
> - respect existing conventions even if you don't like them
>
> What does that mean exactly (In terms of the current context)?
This is a general rule, and it's not targeting you. It's for everyone, me
included. The perfect example is that I should not have told you 'go'
without asking Alex before.
Also, if it's not broken don't fix is VERY ambiguous.
> Lets just stick to facts and concepts ok? Communicate clearly
> and simply with examples if necessary.
Just a general sentence. I try to say 'focus on serious issues'. We are
still waiting the RPM packager you promized month ago, and DAS is serious
business too. Don't get lost in small details. Keep the good work on, keep
focus on DAS, you are close to a good solution, I think.
You said do it. Alex said don't do it.
>
> This is a democracy. We all have to agree before
> something is done. That means we have to discuss
> it and make sure everyone has clearly understood each other's
> rationale.
Sometime it's a litle bit more complicated. This is a meritocracy. Alex
merit is enormous, and we should respect that. Even if he is wrong, he
deserves respect. We all owe him a lot, because he started this project.
When he says "don't", I back him, just because Alex is 99% right, when i'm
only 50%. I won't fight for the 1%, if it's not important.
Now, we can discuss things, but this is not because we don't agree that you
are right. (Churchill)
>
> True.
Yep. Shit happens. We do mistake, all of us. I'm sorry if you have to revert
code you have already changed, and spoiled time.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
| |
| Ole Ersoy 2007-04-19, 1:11 pm |
|
Emmanuel Lecharny wrote:
> Ole,
>
> On 4/19/07, *Ole Ersoy* <ole.ersoy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> <mailto:ole.ersoy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>> wrote:
>
> Hey Alex,
>
> You do have auto complete you know :-)
>
>
> This is not the problem.
>
> The original idea here was to minimize the
> learning curve for future contributors and
> code reviewers.
>
>
> Using AT and OC should not be a real problem. If you are down to the
> code where you are using those abbreviations, then it means you already
> have a certain level of knowledge about what is what in Ldap.
Basically what you are saying here is that once you know the code
you understand it. Sure. Naturally. I get it now too. For me
there is very little value now in changing AT and OC.
It's only for beginners.
The way I see it, if the code base is easier to understand, ADS will
attract more developers and reviewers.
SNIP
>
> 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.
>
>
> Ole, we are aware of that. I think we all have a serious background in
> coding...
Yes - I know. The reason I pointed that out is because Alex said this:
========================================
==================
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.
========================================
==================
So I wanted to make sure the record was clear on what the purpose of
the constant is.
Also now that I'm reviewing it more closely, I actually think using the
constant can greatly enhance the "Digestability" of some of these
short abbreviations that LDAP uses.
When something is spelled out clearly, so that it is immediately
recognizable to someone who is seeing it for the first time,
it makes development easier.
>
>
> There are so many abbreviations in LDAP, like
> ou, cn, sn....that when more get added the cognitive
> load is pretty significant for beginners.
>
>
> On the opposite, Ldap is not simple. RFCs which describe LDAp are huge :
> probably around 500 pages if you gather all of them. Don't excpect LDAP
> to be simple. The coginitive load *is* significant, even for
> experimented players...
Yes - I agree. I just try to make everything as simple as possible.
When starting with any apache project, there's typically so much to
learn to become a productive contributor that every little bit helps.
>
> <snip>
> I think ApacheDS will be more popular for contributors
> when the code base is as simple as possible to work with.
>
SNIP
BTW - Thanks for commenting in detail. This is a good discussion.
A little long perhaps for something this trivial :-), but still gooddd.
I invest my time in this, not so much because I consider making OC
and AT simpler, but more because of the general philosophy behind
making things simple. My view is that if it can be made simpler,
this will help others, and by helping others, the server gets better
because more people will want to work with the code.
Cheers,
- Ole
| |
| Stefan Zoerner 2007-04-19, 1:11 pm |
| Ole Ersoy wrote:
> 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?
Although I am also still a newbie within the code, I do not like to
change the constant names. They are defined in public
interfaces/classes, and we do not know whether there are users out there
which use these constants in their custom partitions, custom
interceptors etc.
For instance the public class
org.apache.directory.shared.ldap.constants.SchemaConstants
is in no way marked as internal API.
If we rename the constants, we have at least to leave them with the old
names in the class, mark them as deprecated in order to give these
ApacheDS users a chance to refactor their code, and remove them in a
later release.
I see no benefit in renaming the constants which corresponds to the
effort related with this mandatory process.
By the way, I like "TOP_OBJECT_CLASS" better than "TOP_OC", my personal
favorite would be "TOP_OBJECTCLASS", but as Emmanuel already pointed
out: It works, so why should we change it? "TOP_OC" is clear enough,
although it lacks javadoc (which could be "name of objectClass top").
Greetings,
Stefan
| |
| Alex Karasulu 2007-04-19, 1:11 pm |
| Hi Ole,
On 4/19/07, Ole Ersoy <ole.ersoy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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
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.
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. 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
>
>
>
>
>
>
>
> Alex Karasulu wrote:
>
| |
| Emmanuel Lecharny 2007-04-19, 1:11 pm |
| Hi Stefan,
On 4/19/07, Stefan Zoerner <stefan-EQq9qWhC7IA@public.gmane.org> wrote:
>
>
> Although I am also still a newbie within the code, I do not like to
> change the constant names. They are defined in public
> interfaces/classes, and we do not know whether there are users out there
> which use these constants in their custom partitions, custom
> interceptors etc.
This is so right !
We were lucky here, because I just pushed the classes quite recently, but
it's now in the 1.5.0 code base...
Those constants are related to the new dynamic Schema, so I guess it's too
late to change them, as they are already used by LdapStudio and other
projects.
If we rename the constants, we have at least to leave them with the old
> names in the class, mark them as deprecated in order to give these
> ApacheDS users a chance to refactor their code, and remove them in a
> later release.
Exactly.
By the way, I like "TOP_OBJECT_CLASS" better than "TOP_OC", my personal
> favorite would be "TOP_OBJECTCLASS", but as Emmanuel already pointed
> out: It works, so why should we change it? "TOP_OC" is clear enough,
> although it lacks javadoc (which could be "name of objectClass top").
Sure. Let's add Javadoc then, I was lazzy when I created the classes : I
added a simple comment when a javadoc would have been better.
Stefan, it's a pleasure to have you in the team 
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
| |
| Ole Ersoy 2007-04-19, 1:11 pm |
|
Emmanuel Lecharny wrote:
SNIP
> I said, 'do it', then alex said don't. And he explained why. I respect
> Alex rationals, and I may have said 'do' a little bit too quickly. My bad.
>
>
> What does that mean exactly (In terms of the current context)?
>
>
> This is a general rule, and it's not targeting you. It's for everyone,
> me included. The perfect example is that I should not have told you 'go'
> without asking Alex before.
Ah - OK. That makes sense.
>
> Also, if it's not broken don't fix is VERY ambiguous.
> Lets just stick to facts and concepts ok? Communicate clearly
> and simply with examples if necessary.
>
>
> Just a general sentence. I try to say 'focus on serious issues'. We are
> still waiting the RPM packager you promized month ago, and DAS is
> serious business too. Don't get lost in small details. Keep the good
> work on, keep focus on DAS, you are close to a good solution, I think.
Yeah - I think we're getting close :-)
In general if I see something I think can be made better,
I suggest it and clarify my rationale. There's no rush
to do these things.
What I was looking at in this case was that if I refactor
the constants now, it means that I don't have to do it later,
which I like. I try to take care of some trivial thing right up front
when possible. But if we all don't like then it stays, and we get
on with the serious business.
>
> You said do it. Alex said don't do it.
>
> This is a democracy. We all have to agree before
> something is done. That means we have to discuss
> it and make sure everyone has clearly understood each other's
> rationale.
>
>
> Sometime it's a litle bit more complicated. This is a meritocracy. Alex
> merit is enormous, and we should respect that.
Agree
> Even if he is wrong, he
> deserves respect.
Agree
> We all owe him a lot,
> because he started this project.
Agree
> When he says "don't", I back him, just because Alex is 99% right, when
> i'm only 50%. I won't fight for the 1%, if it's not important.
My philosophy is to make sure I'm clearly understood and if I see
something where I think the rationale is off I point it out.
I back "I understand your rationale, but like it like this so don't
change it". That's fine.
It's ok to agree to disagree :-)
> Now, we can discuss things, but this is not because we don't agree that
> you are right. (Churchill)
> True.
>
>
> Yep. Shit happens. We do mistake, all of us. I'm sorry if you have to
> revert code you have already changed, and spoiled time.
No biggie. It's a very trivial change. I think we just thought Alex
was on board, because the boat was docked for a long time, but we are all
busy and don't necessarily see all the mails right away, ces't la vie.
Cheers,
- Ole
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com <http://www.iktek.com>
| |
| Alex Karasulu 2007-04-19, 1:11 pm |
| Hi all,
On 4/19/07, Emmanuel Lecharny <elecharny-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>
>
> On 4/19/07, Ole Ersoy <ole.ersoy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>
> I said, 'do it', then alex said don't. And he explained why. I respect
> Alex rationals, and I may have said 'do' a little bit too quickly. My bad.
>
We no you did ok Emmanuel. This is why we have a community. We all may not
consider all the ramifications.
Stefan Seelman I just noted responded with a very valid concern. Why change
a public interface out of a whim when other's may depend on it. He's right
and his justification for not making the changes were more compelling than
mine. I just don't want to type more or have to break up lines of code with
big constants rather than logic in the code. LAPTOP screen realestate is
limiting for me.
But back to Emmanuel's 'do it'. This is fine. We all need to speak our
minds and there is nothing wrong with that ... things need to be put on the
table right? And objectors must stand up and object supplying their
rational. So don't worry we took care of it.
> - respect existing conventions even if you don't like them
>
>
> This is a general rule, and it's not targeting you. It's for everyone, me
> included. The perfect example is that I should not have told you 'go'
> without asking Alex before.
>
Again I think you did what you thought was right and that's ok.
Also, if it's not broken don't fix is VERY ambiguous.
>
>
> Just a general sentence. I try to say 'focus on serious issues'. We are
> still waiting the RPM packager you promized month ago, and DAS is serious
> business too. Don't get lost in small details. Keep the good work on, keep
> focus on DAS, you are close to a good solution, I think.
>
Yes I agree with this completely. This not a critical issue but after
Stefan Seelmann's commentary I will have to agree that we must not change
these public constants without the deprecation process.
BTW Ole the DAS stuff you're doing is very cool. I hope this little
disagreement does not take focus away from that. That is a serious matter
for us all and the convention for constant naming is not.
You said do it. Alex said don't do it.
>
>
> Sometime it's a litle bit more complicated. This is a meritocracy. Alex
> merit is enormous, and we should respect that. Even if he is wrong, he
> deserves respect. We all owe him a lot, because he started this project.
> When he says "don't", I back him, just because Alex is 99% right, when i'm
> only 50%. I won't fight for the 1%, if it's not important.
>
Well I do want people to leverage my experience in this stuff to do the
right thing. Not just to listen to me. I want people to challenge my ideas
and I am wrong several times. So without that I can mislead this project.
Please keep questioning but please read and try to absorb what I am saying
instead of overlooking my comments.
Alex
| |
| Alex Karasulu 2007-04-19, 1:11 pm |
| Ole,
On 4/19/07, Ole Ersoy <ole.ersoy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>
> Emmanuel Lecharny wrote:
> because he started this project.
> Agree
>
> My philosophy is to make sure I'm clearly understood and if I see
> something where I think the rationale is off I point it out.
>
> I back "I understand your rationale, but like it like this so don't
> change it". That's fine.
> It's ok to agree to disagree :-)
Please, please do so. This is important and voices should not be quieted
for any reason especially by us old farts that have done things one way for
so long that we might not see anything better. You're a proponent for
change and we need that.
> Now, we can discuss things, but this is not because we don't agree that
>
> No biggie. It's a very trivial change. I think we just thought Alex
> was on board, because the boat was docked for a long time, but we are all
> busy and don't necessarily see all the mails right away, ces't la vie.
Yeah NP let's just forge ahead bro. We have too many issues to fixate on
these small matters and sh*t just happens.
Alex
| |
| Stefan Seelmann 2007-04-19, 1:11 pm |
| Alex Karasulu schrieb:
> Stefan Seelman I just noted responded with a very valid concern. Why
> change a public interface out of a whim when other's may depend on it.
> He's right and his justification for not making the changes were more
> compelling than mine. I just don't want to type more or have to break
> up lines of code with big constants rather than logic in the code.
> LAPTOP screen realestate is limiting for me.
>
> ...
>
> Yes I agree with this completely. This not a critical issue but after
> Stefan Seelmann's commentary I will have to agree that we must not
> change these public constants without the deprecation process.
>
Alex, thanks for the compliments. But it was Stefan Zoerner's comments,
so please praise him ;-)
Regards,
Stefan Seelmann
| |
| Stefan Zoerner 2007-04-19, 7:11 pm |
| Stefan Seelmann wrote:
>
> Alex, thanks for the compliments. But it was Stefan Zoerner's comments,
> so please praise him ;-)
>
> Regards,
> Stefan Seelmann
My fault. I'll sign with my complete name in the future to avoid
ambiguousness.
Greetings from rainy Hamburg,
Stefan Zoerner (szoerner)
| |
| Ole Ersoy 2007-04-19, 7:11 pm |
|
Alex Karasulu wrote:
> Hi Ole,
>
> On 4/19/07, *Ole Ersoy* <ole.ersoy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> <mailto:ole.ersoy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>> 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
| |
| Ole Ersoy 2007-04-19, 7:11 pm |
| Hi Emmanuel and Stefan,
Excellent points.
There could be refactoring requirements across the user base.
As I'm sure you realized, this only gets more ingrained as time
passes, which is why it's so important to seriously either do it
now or just leave it permanently.
>
>
> If we rename the constants, we have at least to leave them with the old
> names in the class, mark them as deprecated in order to give these
> ApacheDS users a chance to refactor their code, and remove them in a
> later release.
I was actually wondering how to do the refactoring after Emmanuel said,
"Change the constants, then run the test".
This made me pause for a minute. I'd probably have to checkout the
entire build, to let eclipse have visibility to everything, so that
it refactors all the Java files that use the interfaces when a constant
is changed.
Anyways...
Cheers,
- Ole
| |
| Emmanuel Lecharny 2007-04-19, 7:11 pm |
| Ole,
I think this thread should stop now. People on the list don't really care if
you understand or not that MR means MATCHING_RULE deep inside the server. If
you want to debate other issues like the ones you mentionned in your
previous mail, please do so privately with Alex.
I also think we have addressed your initial point.
let's focus on real stuff now.
PS: no need to answer this mail.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
| |
| Ole Ersoy 2007-04-19, 7:11 pm |
| Alex,
I'm a pushy little baggar :-)
At the end of the day, we all just want ADS and all the other
subprojects to be the best they can be.
So when I think something is important I just push until
I think everything is clearly understood.
At the end of the day though, it's right back to the important
stuff like the DAS and the installer, so no worries bro.
I think we are all good people with good intentions and it's amazing
to see how many great things have happened in a really short time span
with ADS, so I think we all just want to see it get better.
Cheers,
- Ole
Alex Karasulu wrote:
> Ole,
>
> On 4/19/07, *Ole Ersoy* <ole.ersoy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> <mailto:ole.ersoy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>> wrote:
>
>
> Emmanuel Lecharny wrote:
>
>
> Agree
> when
>
> My philosophy is to make sure I'm clearly understood and if I see
> something where I think the rationale is off I point it out.
>
> I back "I understand your rationale, but like it like this so don't
> change it". That's fine.
> It's ok to agree to disagree :-)
>
>
> Please, please do so. This is important and voices should not be
> quieted for any reason especially by us old farts that have done things
> one way for so long that we might not see anything better. You're a
> proponent for change and we need that.
>
> agree that
> bad.
> have to
>
> No biggie. It's a very trivial change. I think we just thought Alex
> was on board, because the boat was docked for a long time, but we
> are all
> busy and don't necessarily see all the mails right away, ces't la vie.
>
>
> Yeah NP let's just forge ahead bro. We have too many issues to fixate
> on these small matters and sh*t just happens.
>
> Alex
>
| |
| Ole Ersoy 2007-04-19, 7:11 pm |
| Emmanuel,
I agree that it's getting a little old and it
ended up drawing out way past what my original intention was.
I do think though that things need to come to a natural completion
and even though some minor points have been unanswered, I'm fine
with just going on with business.
Cheers,
- Ole
Emmanuel Lecharny wrote:
> Ole,
>
> I think this thread should stop now. People on the list don't really
> care if you understand or not that MR means MATCHING_RULE deep inside
> the server. If you want to debate other issues like the ones you
> mentionned in your previous mail, please do so privately with Alex.
>
> I also think we have addressed your initial point.
>
> let's focus on real stuff now.
>
> PS: no need to answer this mail.
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com <http://www.iktek.com>
| |
| Alex Karasulu 2007-04-19, 7:11 pm |
| Ole,
Hey no worries it's all good buddy. Let's just keep rockin. Thanks for the
kind words. I also have a good feeling about you as well.
Regards,
Alex
On 4/19/07, Ole Ersoy <ole.ersoy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> Alex,
>
> I'm a pushy little baggar :-)
>
> At the end of the day, we all just want ADS and all the other
> subpYrojects to be the best they can be.
>
> So when I think something is important I just push until
> I think everything is clearly understood.
>
> At the end of the day though, it's right back to the important
> stuff like the DAS and the installer, so no worries bro.
>
> I think we are all good people with good intentions and it's amazing
> to see how many great things have happened in a really short time span
> with ADS, so I think we all just want to see it get better.
>
> Cheers,
> - Ole
>
>
>
> Alex Karasulu wrote:
> Alex
> vie.
>
|
|
|
|
|