directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: Some inconsistencies in the DN class
Date Tue, 15 Feb 2011 23:00:11 GMT
On 2/15/11 11:12 PM, Stefan Seelmann wrote:
> (back to list, I think Emmanuel sent it by accident to me)
>
> On Mon, Feb 14, 2011 at 3:56 PM, Emmanuel L├ęcharny<elecharny@apache.org>  wrote:
>> Ok, after some cleanup, I come with two sets of restricted constructors :
>>
>> Empty Dn constructors :
>> - Dn()
>> - Dn( SchemaManager)
>>
>> Constructors having a DN (as a string) :
>> - Dn(String)
>> - Dn(SchemaManager, String)
>>
>> Constructors having RDNs (as strings) :
>> Dn(String...)
>> Dn(SchemaManager, String...)
> I don't understand what's the difference between those two groups if one codes
>    new Dn("abc")
> How does the runtime distinguish the two constructors. I have to read
> the spec again...

The Dn(String) uses a DN as a string, and the Dn(String...) is a bit 
more convoluted, as it almost anything which is a String, concatenate 
them to form a valid DN.
>> Cnstructors having a set of RDNs :
>> - Dn(Rdn)
>> - Dn(SchemaManager, Rdn)
> I guess you mean "Rdn..."
Yep.
>> The other constructors are most certainly spurious at this point :
>>
>>   Dn(Rdn child, Dn parent)
>>
>> can be replaced by :
>>
>>   parent.add( child );
>>
>> as the Dn is an immutable class.
>>
>> Is it ok for all of you ?
> I find it a bit inconvenient. If I see that a class has an "add()"
> method I expect that when using that method that the object is
> modified. I think I'd prefer to get rid of all the "add", "addAll" and
> "remove" methods that pretend mutability.

You are probably right. The problem is that if we want to remove the 
add() method, then we need to define a constructor like :

Dn dn = new Dn( "dc=example,dc=com" );
Dn newDn = new Dn( dn, "sn=test" );

Do we want that instead of :

Dn dn = new Dn( "dc=example,dc=com" );
Dn newDn = dn.add( "sn=test" );

?

-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.iktek.com


Mime
View raw message