directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@apache.org>
Subject Re: Some inconsistencies in the DN class
Date Sun, 13 Feb 2011 14:00:12 GMT
>
>
> > The Dn(String, String, byte[], List<Rdn>) constructor is only used inside
> > the server, and I don't think we really need it. I suggest to remove it.
>
> +1, if possible
>

To be chekced...


>
> > Thoughts ?
>
> The Dn(Dn) constructor, I think that is useless and should be removed.
>

It's a copy constructor. IMO, you are right. Doing a dn.clone() is enogh.



>
> So as a result we will have the following constructors, right?
>  Dn(String...)
>  Dn(Rdn...)
>  Dn(SchemaManager, String...)
>  Dn(SchemaManager, Rdn...)
>  Dn(SchemaManager, Dn)
>

We ned also the Dn() and Dn( SxchemaManager). The  Dn(SchemaManager, Dn) is
probably useless...


> There is also an constructor I am missing: to create an DN  based on a
> parent DN and the child RDN. For example
>  Dn(Rdn child, Dn parent)
>  Dn(SchemaManger, Rdn child, Dn parent)
>

Right. Convenient constructors...



>
> Maybe an insane idea, but what about a all-you-can-eat constructor
>  Dn(Object...)
>  Dn(SchemaManger, Object...)
> where the objects can be of type String, Dn, or Rdn? That would allow
> maximal flexibility when constructing an DN. Sometimes you have the
> parent as Dn object and the attribute type and value as string, then a
> simple
>  Dn parentDn = ...;
>  new Dn(schemaManger, "ou", "groups", parentDn);
> would work.
>

Hmmm... I have doubts about this kind of constructor...



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

Mime
View raw message