On 24 October 2010 10:24, Egon Willighagen <egon.willighagen@gmail.com> wrote:

On Sat, Oct 23, 2010 at 4:28 PM, Rajarshi Guha <rajarshi.guha@gmail.com> wrote:
> Hi, I have been investigating the conversion of *Set classes to
> classes based on List. Currently I have successfully converted RingSet
> (and IRingSet) to a subclass of ArrayList<IRing>.

public class RingSet extends ArrayList<IRing> {} ?

> The nice thing is
> that we can pretty much drop the use of RingSetManipulator and the
> common usage of the class reads like the traditional usage of List
> objects (with the caveat that the RingSet behaves as a Set but is
> treated by calling code as a List).

I guess we should rename the class to RingList, fixing another of our

> The problem I am facing is the related to the construction of RingSet
> objects and the module structure. Given that RingSet no longer
> subclasses ICDKObject, it cannot be constructed via
> DefaultChemObjectBuilder.

It cannot have a setup where "RingSet implements ICDKObject"?

> But having RingSet in the data module
> prevents code from the core module writing
> RingSet rs = new RingSet()
> since data is not a dependency of core.

No, but IChemFile would depend on RingSet...

> The easy way out is to put RingSet into core - but I can see why this
> is not a nice solution.

Indeed... we should allows people to choose between a ArrayList and a
Vector based implementation... one is synchronized, the other is

AFAIK , Vector is still around for compatibility reasons , otherwise one could have

Collections.synchronizedList(new ArrayList())


Without looking into code and without any particular use in mind, I would have preference for collections implementing List<T> interface, instead of extending ArrayList<T> class.  This will open the door towards using classes from java.util.concurent package, e.g. like this one


Best regards,


> But at the same time I believe that it is
> correct not to subclass ICDKObject

I think I would need to see the code, but do you mean 'implement
ICDKObject' or 'subclass CDKObject'?

> since it really is just a container
> for rings, and does not have an intrinsic 'chemical properties'.

Indeed... that's why I recently split out ICDKObject from
IChemObject... the former interface taking care of defining

> Are there any suggestions as to how this might be solved?

Can you put up the code somewhere? Perhaps as Gist(s) (I think it
supports multiple files in one gist now)? I do not care about
compiling or not, just want to see what the code looks like...


Dr E.L. Willighagen
Postdoctoral Research Associate
University of Cambridge
Homepage: http://egonw.github.com/
LinkedIn: http://se.linkedin.com/in/egonw
Blog: http://chem-bla-ics.blogspot.com/
PubList: http://www.citeulike.org/user/egonw/tag/papers

Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
Cdk-devel mailing list