I already did the refactoring but your scm change to git came in between so
that I couldn't commit it once i was done.
Michael, just following up the thread.
Am 03.04.2009 4:32 Uhr, schrieb Rickard Öberg:
Hey,
While doing the refactoring for the new persistence I want to include
Michaels suggestion to not let ManyAssociation extend the JDK Collection
classes.
The question then is what semantics to have. I would suggest that a
ManyAssociation is:
* Ordered like a List
* Contains no duplicates like a Set
* Has minimal convenience methods
Which would result in the following:
public interface ManyAssociation<T>
extends AbstractAssociation
{
int count();
boolean add(int i, T entity);
boolean remove(T entity);
T get(int i);
Iterable<T> toIterable();
List<T> toList();
Set<T> toSet();
}
Points:
* I want to specifically keep down the number of helper methods
(isEmpty, remove(i), add(T) etc.) so that it is easy to add Concerns to
it and not have to implement a whole bunch of various methods.
* Add has index, which makes it possible to use it as a list.
* If you need to use the ManyAssociation with JDK-friendly libraries,
use the "to" methods to create wrappers. The List will have Set
semantics though, as that is how ManyAssociation work, and Set will have
List semantics, as that is how ManyAssociations work.
Does this make sense? Any missing methods?
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
--
Michael Hunger
Independent Consultant
Web: http://www.jexp.de
Email: [email protected]
Enthusiastic Evangelist for Better Software Development
Don't stop where you are: http://creating.passionate-developers.org
We support Software Engineering Radio (www.se-radio.net)
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
