On Mon, 2007-01-15 at 17:44 +1100, Edward d'Auvergne wrote:
[snip]
Some asides
A. I believe the runs that are passed around in relax are strings
which are then used to lookup data in a map. Why not just have
(runs/pipes) as objects... Then for example the call
self.relax.data[self.relax.run]
above becomes
self.relax.run.data a much more object orientated and encapsulated
structure
You still need a list (array) or dictionary (hash) type structure to
store multiple run objects. 'self.relax.data' would be a dictionary
type object with key-value pairs, the key being the run name and the
value being a standard class instance object containing all the data
associated with the run as objects. The dictionary would be more
logical than an array in this case.
The issue here is whether the user and/or developer should be dealing
with a run name (a string) or the run object itself. Currently the user
creates a new run with:
run.create(run_name, run_type)
and then uses the string, run_name, to address the object. In this
idiom, a dictionary of runs is clearly an appropriate structure.
Alternatively, we could have the user create a run with:
my_run = run.create(run_type)
Then the user has the run as an object, which they can make current or
pass to relax commands as required. In this idiom, a dictionary of runs
is an unnecessary abstraction.
Currently, the relax interface is entirely script orientated, not object
orientated, so the alternative above is a fairly fundamental change in
interface design.
I don't favour an object orientated user interface, because oo tends to
be fairly intimdating to non-programmers. On the other hand, the relax
code-base could benefit from being more object orientated. So I propose
the following arrangement:
all runs are stored in a dictionary, keyed by run name, but only the
run-selection machinery should access this dictionary. The current run
should be the object self.relax.data.run (or something simiar), and all
relax functions should operate on that object.
Thus we would have user functions:
run.create(run_name, run_type):
self.relax._runs[run_name] = new_run(run_type)
run.make_current(run_name):
self.relax.data.run = self.relax._runs[run_name]
run.current():
return self.relax.data.run.name
run.run_names():
return self.relax._runs.keys()
run.delete(run_name):
if run.current() == run_name:
self.relax.data.run = None
del self.relax._runs[run_name]
run.delete_all():
self.relax.data.run = None
self.relax._runs = {}
This way the abstraction of the dictionary of runs is cleanly hidden
from the developer who chooses to work with objects, but the scripting
style of the user interface is maintained.
Chris
Re: Redesign of the relax data model: 2. A new run concept