Sire

I've been arguing a lot recently - not with anyone else, but with myself. I tend to argue a lot with myself when I am programming, adopting both a pro- and anti- stance against pretty much every design decision. On the plus side, it means that I really think about what I am doing, and the consequences of each decision, and *really* decide. On the negative side it does make me quite schizophenic, and the self-arguments can become very heated! This weekend was quite a good example. For a long time I have held the view that the Molecule class should be as simple as it can be (i.e. holds only geometric, bonding and chemical information and nothing more), thus allowing it to be compatible with all situations. Any extra information that was necessary should be supplied in addition to the molecule and stored where it was needed (e.g. atomic partial charges should be stored in the forcefield, not the molecule). However, recently this design decision has come under fire from the realist in me, who recognises that the code will be much easier to use if the molecule was able to hold additional information, and thus the user was not having to manage lots of additional tables. The realist in me was appalled by the necessity of holding the atomic charges in a separate class instance, and then having to validate that these charges were compatible with the molecule every time they were used with the molecule. After a long and tiring session over the weekend I finally gave in, and accepted that I was right and wrong, and that I needed to allow a molecule to hold additional data. However, that additional data should be optional, and thus, in reality, the molecule is just allowing additional properties to be associated with its minimal design. Indeed, now the molecule is a simple geometric entity, with its own container for arbitrary data. I think that this is perhaps the best compromise, as the core molecule (the non-optional part) is very simple, and represents the minimum that is necessary for the molecule to be recognised as a molecule. The non-optional parts are just user-supplied properties that provide no guarantees, so code should not rely on them unless they truly are required (e.g. AtomicCharges must be added as a property to a molecule that will be added to a coulomb forcefield). Now that I have properties, my Molecules can now finally be used to fully read in structure files, as now any additional information in the file can be added as a property. Of course the big problem now, (and indeed the interesting data modelling problem) is how to standardise the naming and data structure of these completely arbitrary properties...