Matthew Swift a écrit :
public DN(String dnStr) {
return valueOf( dnStr );
}
Nothing will prevent you from writing something like that, but the
compiler will prevent you from compiling it. Get some sleep! ;-)
Doh !!! Yeah, or maybe some stronger coffee ;)
--
Regards,
Cordialement,
Emman
On 14/01/10 23:20, Emmanuel Lcharny wrote:
[...]
But for users, DN(String) covers 99% of their usage. This is how they
created DN with JNDI, and i'm not sure they want something very
different. Now, internally, othing prevent you to write something like :
public DN(String dnStr) {
retur
Matthew Swift a écrit :
On 13/01/10 13:03, Francois wrote:
Le 13/01/2010 12:24, Matthew Swift a écrit :
Hi Emmanuel,
I'm just giveng my point of view about the following, I don't think I
can be relevant elsewhere:
Also, I strongly believe that DNs and RDNs and AVAs should be immutable
o
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
Le 14/01/2010 22:12, Matthew Swift a écrit :
Matthew, thanks for your answer, response inlined :
I understand very well why you think Attribute could be immutable. In
fact, I went to great lengths to convert our Attribute API in OpenDS
server so that it was immutable in order to be able to opti
Matthew Swift a écrit :
On 13/01/10 21:55, Stefan Seelmann wrote:
Matthew Swift wrote:
On 12/01/10 14:29, Emmanuel Lecharny wrote:
Even if you decide that caching is not required then that's no
reason to develop an API which prevents you from implementing one in
future. Using a normal cons
Matthew Swift a écrit :
and Entry should have at least an immutable DN (and facilities to
copy an entry with a new DN or ParentDN at factory level).
If the DN is immutable, entry's DN will be too.
I think Francois is stating that Entry should have a DN getter but no
setter. In other words th
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. Being f
On 13/01/10 21:55, Stefan Seelmann wrote:
Matthew Swift wrote:
On 12/01/10 14:29, Emmanuel Lecharny wrote:
Even if you decide that caching is not required then that's no reason
to develop an API which prevents you from implementing one in future.
Using a normal constructor prevents the use
On 13/01/10 13:34, Emmanuel Lcharny wrote:
Francois a écrit :
Le 13/01/2010 12:24, Matthew Swift a écrit :
Hi Emmanuel,
I'm just giveng my point of view about the following, I don't think I
can be relevant elsewhere:
Also, I strongly believe that DNs and RDNs and AVAs should be immutab
On 13/01/10 13:03, Francois wrote:
Le 13/01/2010 12:24, Matthew Swift a écrit :
Hi Emmanuel,
I'm just giveng my point of view about the following, I don't think I
can be relevant elsewhere:
Also, I strongly believe that DNs and RDNs and AVAs should be immutable
objects (as well as any ot
11 matches
Mail list logo
