On 1/8/07, gary thompson <garyt@xxxxxxxxxxxxxxx> wrote:
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.
I'll definitely try to get my hands on the Design Patterns book
(http://en.wikipedia.org/wiki/Design_Patterns) as I would find it
personally quite useful. There are many poorly designed, although
functional, parts of relax (anti-patterns) which could be
significantly improved over time. The best example would be how I
have set up the specific function setup code
'specific_fns/specific_setup.py'. Once all the unit tests are setup,
these types of refactorisation would be much easier.
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
....
I would like to keep a separation between the UI design and the coding
and structure of the relax internals. The name data pipe or 'pipe' to
replace the name 'run' is a UI thing. The data pipe concept is
neither an object or any type of data structure - how it's implemented
is a different thing though. I believe the UI design should come
first and foremost and then the code made to implement those decisions
as best as possible.
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?
See my post at
https://mail.gna.org/public/relax-devel/2007-01/msg00029.html
(Message-id: <7f080ed10701142244ne7d107bl84582ce604d1888e@xxxxxxxxxxxxxx>)
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....
For certain parts of relax that may be the case. I can identify the
'generic_fns' directory as a likely target. Again though this can be
discussed separately and converted after the redesign and the setup of
the unit tests.
I hope this all helps and doesn't sound too critical ;-)
Not at all, the relax internals could do with a good redesign and
clean out. I learnt how to program by coding relax and there are many
parts, especially some of the ancient code, which could be much better
designed. I'm sure many bugs would be weeded out in the process.
Cheers,
Edward
Re: redesign of the relax data model: 1. Why change?