From: Christoph S. <c.s...@un...> - 2004-09-23 13:40:57
|
Hi everybody, from the very beginning the CDK had a concept of ChangeEvents and=20 Listeners in order to notify interested parties of changes in the core=20 objects. However, this was never really working because the setter=20 methods did not call the notifyChanged() method in ChemObject. Moreover,=20 in nested objects (ChemFile->ChemModel->[...]->AtomContainer->Atom,etc.)=20 a Container object needs to register with its inhabitants as a listener=20 in order to propagate change events. Especially in the case of ChemFile=20 and ChemModel, this is vital. Otherwise, applications would have to=20 register with each atomistic object in order to know about changes. With the describe propagation mechanism at work, however, they just need=20 to register with the top container class, e.g. the ChemModel. The ChemObjectChangeEvent object, containg a reference to the original=20 origin of the change, must be propagate up the chain in order to allow=20 the application to identify the type of object where the change occurred. I have now added notifyChanged() calls to all setter and related methods=20 - i.e. methods, where the data is changed. I'm further working on=20 getting the propagation of events to work in=20 ChemFile/-Model/SetOfMolecules, etc. While doing this, I noticed a slight inconsistency in the core classes.=20 I think, we need to move ChemObjectChangeEvent and ChemObjectListener to=20 the core classes. Otherwise, the policy of not importing CDK subpackages=20 in the core classes is violated. Moreover, ChemObjectListener *is* part=20 of the core and this is certainly inconsistent. Any comments? Cheers, Chris --=20 Dr. rer. nat. habil. Christoph Steinbeck (c.s...@un...) Groupleader Junior Research Group for Applied Bioinformatics Cologne University BioInformatics Center (http://www.cubic.uni-koeln.de) Z=FClpicher Str. 47, 50674 Cologne Tel: +49(0)221-470-7426 Fax: +49 (0) 221-470-7786 What is man but that lofty spirit - that sense of enterprise. ... Kirk, "I, Mudd," stardate 4513.3.. |
From: Egon W. <eg...@us...> - 2004-09-28 17:58:22
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 23 September 2004 15:40, Christoph Steinbeck wrote: > from the very beginning the CDK had a concept of ChangeEvents and > Listeners in order to notify interested parties of changes in the core > objects. However, this was never really working because the setter > methods did not call the notifyChanged() method in ChemObject. Moreover, > in nested objects (ChemFile->ChemModel->[...]->AtomContainer->Atom,etc.) > a Container object needs to register with its inhabitants as a listener > in order to propagate change events. Especially in the case of ChemFile > and ChemModel, this is vital. Otherwise, applications would have to > register with each atomistic object in order to know about changes. Ok, what will happen then in this situation: AtomContainer with one Atom, and I registered with the AC. Say, the Atom changes, do I get change events from both classes? I would=20 expect to get only one from the AC... > With the describe propagation mechanism at work, however, they just need > to register with the top container class, e.g. the ChemModel. > The ChemObjectChangeEvent object, containg a reference to the original > origin of the change, must be propagate up the chain in order to allow > the application to identify the type of object where the change occurred. > > I have now added notifyChanged() calls to all setter and related methods > - i.e. methods, where the data is changed. I'm further working on > getting the propagation of events to work in > ChemFile/-Model/SetOfMolecules, etc. Good. That's the way it was intended, and thus how it should be... Alternatively, in the future we might want to make things interfaces, like= =20 with Octet, so that this listener feature becomes optional... for those in= =20 need of speed. > While doing this, I noticed a slight inconsistency in the core classes. > I think, we need to move ChemObjectChangeEvent and ChemObjectListener to > the core classes. Otherwise, the policy of not importing CDK subpackages > in the core classes is violated. Moreover, ChemObjectListener *is* part > of the core and this is certainly inconsistent. Agreed. Please updated those to classes to be of @cdk.module core... BTW, the fact that they are not in org.openscience.cdk itself is not really= a=20 problem... that package does not constitute core classes... IIRC, it always= =20 contained none core classes... Egon =2D --=20 eg...@us... GPG: 1024D/D6336BA6 =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBWaY1d9R8I9Yza6YRAnpWAJ9pl0gW6Wznez1Baa3SgE0x3LRjUgCgtxv9 hbVJX++fWCob20SSzfQNHsE=3D =3D4Wga =2D----END PGP SIGNATURE----- |
From: Christoph S. <c.s...@un...> - 2004-09-29 08:23:41
|
Egon Willighagen wrote: > Ok, what will happen then in this situation: >=20 > AtomContainer with one Atom, and I registered with the AC. >=20 > Say, the Atom changes, do I get change events from both classes? I woul= d=20 > expect to get only one from the AC... You get what you ask for. :-) If you register with both the Atom *and* the AC, you will of course get=20 both change events. But with the propagation scheme, this is not=20 necessary, since both ChangeEvent object will have the same atom object=20 returned by ChangeEvent.getSource(). So it is sufficient to register=20 with the AC. > Alternatively, in the future we might want to make things interfaces, l= ike=20 > with Octet, so that this listener feature becomes optional... for those= in=20 > need of speed. That's right. However, I carefully observed the implications of my changes. The run=20 time of the tests (on my laptop) when from 7.5 seconds before the=20 introduction of listeners to 7.8 seconds after. This is perfectly acceptable. Just to make this clear. A move to an everthing-is-an-interface concept=20 would be highly desirable nevertheless. Cheers, Chris --=20 Dr. rer. nat. habil. Christoph Steinbeck (c.s...@un...) Groupleader Junior Research Group for Applied Bioinformatics Cologne University BioInformatics Center (http://www.cubic.uni-koeln.de) Z=FClpicher Str. 47, 50674 Cologne Tel: +49(0)221-470-7426 Fax: +49 (0) 221-470-7786 What is man but that lofty spirit - that sense of enterprise. ... Kirk, "I, Mudd," stardate 4513.3.. |
From: E.L. W. <eg...@us...> - 2004-09-30 07:36:20
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 29 September 2004 10:23, Christoph Steinbeck wrote: > Egon Willighagen wrote: > > Ok, what will happen then in this situation: > > > > AtomContainer with one Atom, and I registered with the AC. > > > > Say, the Atom changes, do I get change events from both classes? I would > > expect to get only one from the AC... > > You get what you ask for. :-) > If you register with both the Atom *and* the AC, you will of course get > both change events. But with the propagation scheme, this is not > necessary, since both ChangeEvent object will have the same atom object > returned by ChangeEvent.getSource(). So it is sufficient to register > with the AC. Ok, that sounds good... I thought you meant that I would get the event call= s=20 from both the Atom and the container... i.e. the same message twice... > > Alternatively, in the future we might want to make things interfaces, > > like with Octet, so that this listener feature becomes optional... for > > those in need of speed. > > That's right. > However, I carefully observed the implications of my changes. The run > time of the tests (on my laptop) when from 7.5 seconds before the > introduction of listeners to 7.8 seconds after. > This is perfectly acceptable. Ok, that's not bad... how does it scale? Egon =2D --=20 eg...@us... =2D --------------------------------------- CDK: http://cdk.sf.net/ JChemPaint: http://jchempaint.sf.net/ Jmol: http://www.jmol.org/ =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (SunOS) iD8DBQFBW7dkd9R8I9Yza6YRAveEAJ9dY1vJYgpDHmIX2s3aXa2sIVWf0gCeLEtd IUhu6GngwsuTZeCMwkzEvXc=3D =3DpwQ9 =2D----END PGP SIGNATURE----- |
From: Christoph S. <c.s...@un...> - 2004-09-30 08:31:58
|
>>That's right. >>However, I carefully observed the implications of my changes. The run >>time of the tests (on my laptop) when from 7.5 seconds before the >>introduction of listeners to 7.8 seconds after. >>This is perfectly acceptable. >=20 >=20 > Ok, that's not bad... how does it scale? Good question. We don't know yet, but the almost 600 tests which are run=20 in the CDK test suite contain pretty heavy stuff (large ring systems,=20 etc.), so I guess it scales very good. Cheers, Chris --=20 Dr. rer. nat. habil. Christoph Steinbeck (c.s...@un...) Groupleader Junior Research Group for Applied Bioinformatics Cologne University BioInformatics Center (http://www.cubic.uni-koeln.de) Z=FClpicher Str. 47, 50674 Cologne Tel: +49(0)221-470-7426 Fax: +49 (0) 221-470-7786 What is man but that lofty spirit - that sense of enterprise. ... Kirk, "I, Mudd," stardate 4513.3.. |