Matthew Swift a écrit :
On 14/01/10 00:43, Emmanuel Lcharny wrote:
[...]
Well, I don't really think that it's anything but implementation
dependent, so from the API POV, it's irrelevant. As soon as we add
the valueof() methods, those who want to add a cache can do it.
It's very relevant from an API POV.
Sorry, you don't caught what I wanted to express, or I wasn't able to
express what I had in mind.
I meant that discussing this point is irrelevant, just because having
both the constructor *and* the valueof makes sense to me now.
Being future proof is an essential part of any API. Client
applications will need to be modified if a valueOf constructor is
added at a later date in order to take advantage of any potential perf
improvements. By including the valueOf initially applications can
choose to use the constructor knowing that they will inherit any
future improvements such as caching.
On the same page.
If for learnability reasons we decide that a DN(String) constructor is
required then so be it, but it should include Javadoc recommending
that users use the valueOf constructor in preference.
Well, here, I disagree. Users are smat enough to understand the
difference between both methods to create objects, and i don't thik we
have to stress it out, otherwise people will keep asking 'why are you
keeping those two guys in the API ?'
Also, I strongly believe that DNs and RDNs and AVAs should be
immutable objects (as well as any other low level API type). What do
you think?
DN and RDN should be immutable, sure. AVA, I have some doubt.
If AVA is mutable then it is impossible for DN and RDN to be immutable
unless they do defensive copies which will be a bit annoying.
I'm probably confusing the creation of AVA and the presence of setters.
Anyway, if AVAs is not visible, it' s a non issue.
Also, on the subject of AVAs - we have the AVA type as an inner
class in RDN. I'm not particularly happy with this this, but less
happy with it being a standalone class since AVAs are only used in
RDNs and may introduce confusion elsewhere. For example, filters
also use attribute value assertions but these are not the same type
of object as an AVA even if they have the same name. For example,
AVAs (in RDNs) do not allow attribute options or matching rules to
be specified.
I don't really like inner classes in this case for two reasons :
- It will be a big class, and the RN class while be hundreds of line
long. Not cool
- If we just use an Inner class just because we want to hide it from
the other classes, then I think it's probably better to have it
package protected (ie, no qualifier for this class).
If it's package protected then the class will not be part of the
public API. I'm not sure that I understand?
Well, it's to protect the class from being used (then no need to make it
immutable ;)
