On Tue, Feb 15, 2011 at 11:18 PM, Alex Karasulu <[email protected]> wrote: > On Wed, Feb 16, 2011 at 12:12 AM, Stefan Seelmann <[email protected]> > 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 <[email protected]> >> 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") > > One is schema aware and the other is not. Schema aware Dn parsing takes into > account valid assertion values based on the syntax of the assertion > attribute type. > >> >> How does the runtime distinguish the two constructors. I have to read >> the spec again... >> > > This is our own doing rather than something found in a spec. Basically if > there is a schema manager available syntax constraints are applied, > otherwise they are not.
Sorry, I wasn't clear. I meant the difference between Dn(String) and Dn(String...) Same for the difference between Dn(SchemaManger, String) and Dn(SchemaManager, String...) >> > Cnstructors having a set of RDNs : >> > - Dn(Rdn) >> > - Dn(SchemaManager, Rdn) >> >> I guess you mean "Rdn..." >> >> > The other constructors are most certainly spurious at this point : >> > >> > Dn(Rdn child, Dn parent) >> > > > BTW with this kind of construct I'd follow what things like File( parent, > "child" ) do. The parent comes before the child component. Good point. However the file system path is built from left to right: /root/grandparent/parent/child/grandchild But the DN is built from right to left: o=grandchild,o=child,o=parent,o=granparent,dc=root >> > 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. >> > > +1 > The add() methods make it seem like Dn is mutable like a list.add(). > Thanks, > Alex >
