> > To extend things a bit further, we could incorporate all of this with a
> > functor similar to that proposed for handling multiple run selections
> > (https://mail.gna.org/public/relax-devel/2007-01/msg00013.html and
> > https://mail.gna.org/public/relax-devel/2007-01/msg00020.html ). Of
> > course the spin functor would opperate at a different level of code to
> > the run functor - whereas all user functions would be instances of the
> > run functor, only certain internal functions (those that act on a single
> > spin) would be instances of the spin functor.
>
> The user functions are instances of the run functor? Do you mean the
> functions called by the user functions are instances?
No. In my interpretation of Gary's initial suggestion (gary:
https://mail.gna.org/public/relax-devel/2007-01/msg00013.html and me:
https://mail.gna.org/public/relax-devel/2007-01/msg00020.html ), each
relax user command is an instance of a functor which catches the runs
argument if passed, impliments the run loop (or run stack in Gary's
implimentation), and calls the relevant function in prompt/
I see what you mean. We could implement this in the file
'prompt/interpreter.py' and pass in the functions to the functor
class, overwriting the function in the user function class with the
instance. I do see a problem though and that is how this will affect
the docstrings and the relax help system.
Then all internal relax functions act only on the current run.
That would be best.
Because spin selection is used differently by different relax functions,
and because there is no concept of a 'current spin', my suggestion of a
spin functor lacks the generality and elegance of Gary's idea, but it
might still be worth considering for its code simplification potential.
There are plenty of functions in relax that opperate on a single spin,
and there will be plenty of occasions where we need to code something
like:
'>
for spin in spin_loop(selection):
do_something(spin)
The spin functor idea is simply that this code can be replaced with:
do_something(selection)
where the 'function' do_something is in fact an instance of the spin
functor:
class Spin_command():
def __init__(self, function):
self.function = function
def __call__(self, *args, **kwds):
if 'selection' in kwds.keys():
selection = kwds['selection']
del kwds['selection']
for spin in spin_loop(selection):
args.insert(0, spin)
# or kwds['spin'] = spin
# depending on the agreed syntax of function
self.function(*args, **kwds)
The gain in simplicity is arguably marginal, but there will be a lot of
examples where it might apply.
If we have both the spin_loop and the spin_command, then the developer
can choose the best option as needed. I thought you meant completely
dropping the spin_loop concept. Chris, would you like to add the idea
to the 'docs/data_model_redesign' file (as well as any other ideas
which have been discussed)?
Cheers,
Edward
P.S. I'll respond to the rest of the post in a second message.
Re: Redesign of the relax data model: 3. Molecules, residues, and spins