mailRedesign of the relax data model: 1. Why change?
On Wed, 2006-10-11 at 17:02 +1000, Edward d'Auvergne wrote:
This post is proposal for the redesign the relax data model. This will
affect how data is input into the program, how data is selected, how
molecular structures are handled, how spin systems are handled, and how
many other parts of relax function. Importantly the internal structure
of 'self.relax.data' will completely change. These modifications will
essentially break every part of relax (the isolated code in the
directories 'minimise', 'maths_fns', and 'docs' will be safe from the
carnage, as will a few files in the base directory). If you have any
ideas for extending or improving the proposed data model, can see any
short-comings, deficiencies, or flaws, are familiar with the PDB
conventions, etc., your input is very much sought after. The changes
should occur in the 1.3 line of the repository. 1.2 versions will be
unaffected - scripts will remain compatible and the 1.2 line will
continue to be supported with bug fixes, etc.
I have to apologise in advance for the size of this proposal, to
simplify it I have divided the text into numbered sections. Once this
initial parent message has been sent I will respond to it with the text
of the 4 major sections. This will allow 4 major threads to branch off
from this message on the mailing list archive
(https://mail.gna.org/public/relax-devel). If you have an opinion,
idea, etc. about a specific section, could you please post a separate
message in response to the relevant major section post? Also if you
have unrelated ideas for one of these sections, could you post these as
separate messages as well? For example if you have separate points
about sections 3.1 and 3.5.1, two different posts responding to the
parent Section 3 post would be appreciated. Thanks. This will help to
focus each discussion point into specific threads.
Edward
....
As a general comment if redesign of relax is in progress it would be
worth thinking of what the best exemplars of object oriented design
are and to study them. This is in some way made easy as the current
orthodoxy is well described by object orientated models
(http://ootips.org/ood-principles.html,
http://www.accu.org/acornsig/public/articles/ood_intro.html) and the
idea of design patterns
(http://en.wikipedia.org/wiki/Design_pattern_(computer_science) ).
Design patterns highlight patterns of software design that have been
found to work in a number of systems (anti-patterns do the opposite)
and therefore have been tested in the wild. I would recommend a quiet
evenings reading curled up with Gamma, Erich; Richard Helm, Ralph
Johnson, and John Vlissides (1995). Design Patterns: Elements of
Reusable Object-Oriented Software, hardcover, 395 pages,
Addison-Wesley. ISBN 0-201-63361-2. could provide some useful input.
As you can see this is not the only book on patterns that is in the
wild but is the classic.
The other classic thing is to go through (again?) the structures,
nouns and verbs that are present in you head about the structure,
data, and organization of relax and relaxation systems and think of
them as objects and then think if they would model well into relax.
e.g. structure
pipe
algorithm
data - tensor
- model
....
Certainly there are areas where relax is not very object orientated or
shows some anti patterns. Thus for example self.relax is a very wide
interface which references all the functions in relax as objects many
of which just use there __init__ to save yet another copy of relax
into self.relax. Is this structure still needed when we have a global
relax variable? Surely most of these functions would be better as
static methods of just plain functions in modules and the internals
of the relax class would become much cleaner and leaner. Furthermore
much more organizational overhead would be passed off to the
pythonpath and python import infrastructure... In general classes are
not needed for things that don't have state....
I hope this all helps and doesn't sound too critical ;-)
regards
gary
Re: redesign of the relax data model: 1. Why change?