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 "" represents 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.
Jon Roberts www.mentata.com