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

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

Just as suggested by pam, AT stand for ATTRIBUTE_TYPE, not ATTRIBUTE

On 4/19/07, Emmanuel Lecharny <elecharny-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:[vbc
ol=seagreen]
>
> 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
>
>[/vbcol]


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

[ Post a follow-up to this message ]

-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:[vbc
ol=seagreen]
>
> Just as suggested by pam, AT stand for ATTRIBUTE_TYPE, not ATTRIBUTE
>
> On 4/19/07, Emmanuel Lecharny <elecharny-Re5JQEeQqe8AvxtiuMwx3w@public.gma
ne.org > wrote: 
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com[/vbcol]

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

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.g
mane.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@pub
lic.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>
>
>

[ Post a follow-up to this message ]

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] 

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

David,

On 4/19/07, David Jencks <david_jencks-/E1597aS9LQAvxtiuMwx3w@public.gmane.org> wrote:[vbcol
=seagreen]
>
> 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)[/vbcol]


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

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]