On Jan 18, 2008, at 9:13 AM, Rajarshi Guha wrote:


On Jan 18, 2008, at 8:42 AM, Egon Willighagen wrote:

On Jan 18, 2008 2:36 PM, Rajarshi Guha <rguha@indiana.edu> wrote:
Hmm. Well I think going the IElement route is a good idea. So
IAtom.getSymbol() would access the symbol via the IElement field (for
normal atoms). How would it work for pseudo atoms?

And IAtom.getAtomicNumber() would do it via the IElement as well? ANd
a pseudo atom could just return 0

This is the current behavior, I think...

I guess you mean that we add a stub in the new IAtom with an  
IElement as field?

OK, so I finally looked at the sources (as I should have done in the  
beginning!).

If IAtom is a child of IElement, why should it have a field for an  
IElement?

Also, I'm wondering whether there is any need for the getLabel/ 
setLabel methods in IPseudoAtom?
Wouldn't it be better to remove them, so that the ysmbol is accessed  
by getSymbol() just like for any other atom? But getAtomicNumber  
would be overridden to return a hard coded 0? The advantage is that  
one does not need to inspect the class via instanceof to detect a  
pseudo atom (though one could do it if required). Instead one can  
simply check te aotmic number. Of course this assumes, that for all  
real atoms, the atomic number is set properly


I don't know the code details here, but this is related to something I've wanted to get to for a while. We have a lot of molfiles that come out of our system with various text labels. In essence, the structure file is really a display file.  Obviously a lot of the uses of this are really bad practice, but 1) that's what we have and 2) there are a lot of very interesting uses for display only elements on a structure. Generally display programs will display what returns from getSymbol() (or equivalent), so usually the files we have now will end up with some 'R's scattered about the display. I certainly wouldn't mind having the label stored as the symbol as then this could be fixed with no change in all the display codes, but I don't know what the larger  consequences are of having substantial strings in the symbol field. Then there is still the problem of identifying it as a non-element. Having getAtomicNumber( return 0 (or null) would work, but are there multiple ways of being a non-element that we would have to distinguish?

DanZ


/********************************************
   Daniel Zaharevitz
   Chief, Information Technology Branch
   National Cancer Institute
   zaharevitz@dtpax2.ncifcrf.gov
********************************************/