Re: [Cdk-devel] Delay 1.2.x release, remove functionality, or release with known bugs?

[gilleain t. <gil...@gm...>]

Well, as for Polymer.clone, there are some problems with the method.
When translated to java 5 it looks like:

     Polymer clone = (Polymer) super.clone();
        clone.removeAllElements();
        for (String monomerName : clone.getMonomerNames()) {
        	Monomer monomerClone = (Monomer)
(clone.getMonomer(monomerName).clone());
        	for (IAtom atom : monomerClone.atoms()) {
                   clone.addAtom(atom, monomerClone);
            }
        }
        return clone;

which is a little confusing, as the clone would not have any monomers,
surely, as it is the result of a call to super.clone.

Am I wrong in thinking that the code should be:

  for (String monomerName : this.monomers.keySet())...

??

gilleain

On Sat, Jan 3, 2009 at 9:20 AM, Egon Willighagen
<ego...@gm...> wrote:
> Christoph, Rajarshi and others,
>
> I very much like to hear your thoughts on the following. Currently,
> there are 3 issues which recently showed up upon which I want to make
> a resolution on whether they need fixing before the CDK 1.2.0 release,
> or release with those issues.
>
> I. IPolymer.clone() variants are inconsistent
>
> Being core interfaces, this is rather critical. Three options:
>
> 1. delay 1.2.0 with another 2 months and fix it
>
> >From the word ordering, you can guess my opinion. I have not checked,
> but expect this already to be present in the 1.0.x releases too.
>
> 2. remove from the core interfaces
> 3. release with the bug
>
> II. resolve "with/-out explicit hydrogen, same calculated value" issue
> for molecular descriptors
>
> 1. fix things before release
> 2. remove affected descriptors from release
> 3. release with the bugs
>
> III. The XlogP descriptor is unmaintained and broken
>
> 1. fix the code
>
> I had a brief look at it, but does internal atom type perception,
> which seems rather unstable. No idea how to get this fix, and I'd rely
> on patching here. Post 1.2.0 I am willing to reimplement the
> descriptor using the CDK atom type perception.
>
> 2. remove the descriptor from release
> 3. release broken, untested code, of which we have zero clues of stupidity
>
> (again, you can guess my opinion on that option)
>
> Egon
>
> --
> ----
> http://chem-bla-ics.blogspot.com/
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Cdk-devel mailing list
> Cdk...@li...
> https://lists.sourceforge.net/lists/listinfo/cdk-devel
>