Michael Ströder wrote:
Marc Boorshtein wrote:
>I wanted to get an opinion from the other java ldap projects. Should
>the toString() method of a class that represents a DN return null or
>an empty string? I would think an empty string but JLDAP returns
>null. Anyone have an opinion on the matter?
Not a strong one, since I don't make use of DN.toString(). In my view
the DN utility class is for deconstructing, analyzing, and comparing
non-trivial distinguished names... I invariably have the string version
to begin with.
It really depends on what you want to express. Note that ""
the rootDSE or root naming context. So "" would reference something
existing or well-defined. IMHO NULL (or None in Python) would better
signal something undefined or none-existing.
This was my first thought, but according the source as I read it these
cases would not be distinct: if there are no parent RDNs superior to the
entry reflected in the represented DN, toString() will return null.
Since there is a no-argument constructor DN(), perhaps the original
thinking was that null and the rootDSE "" are synonymous. On the other
hand, the existence of this constructor makes as much sense to me as the
redundant addRDN() and addRDNToFront() methods (ie. none at all). I
suppose *somebody* may want to build a DN instance iteratively, but I
would consider it easier to do so concatenating strings for submission
to the more relevant constructor with argument.
This exercise in software archeology underscores a major reason I think
JLDAP is latent: a lot of cruft but nobody of original authorship to
explain or clean it up. As for the rest of us, if nobody touches it
nobody breaks it, so there it sits. My 2c.