I did some brainstorming about this. I'm not satisfied with the design of Fqn as it is.
While components of the Fqn may be Object, if one wants to be a List be the component
of an Fqn he would have to cast the List to Object to call the intendet constructor
(which is not at all intuitive):
Fqn
norbert wrote :
|
| While components of the Fqn may be Object, if one wants to be a List be the
component of an Fqn he would have to cast the List to Object to call the intendet
constructor (which is not at all intuitive):
|
| Fqn fqn = new Fqn((Object)list);
|
|
I don't think
Although I'm not using FQNs with elements other than String right now I think reducing
this to String-only makes the concept of FQN significantly less powerfull. Constrains
for keys in FQNs should be more or less equivalent to keys in Maps (e.g. must
implement 'equals()')
I'd rather see that
I have thought about such a solution as well. The thing is that when you store
{1,2,3}, you will get back {1,2,3}. Comparison in this case would fail.
Hmm, maybe we leave it, document this, and see how people like it.
Thanks for the input,
View the original post :
