> > 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.
>
> I agree, however I would extend this using the global variable ideas
> Gary proposed
(https://mail.gna.org/public/relax-devel/2007-01/msg00013.html,
> Message-id: <f001463a0701071314i61276e67hde685fe3afb8fe42@xxxxxxxxxxxxxx>).
> So instead of using 'self.relax.data.run' the data container of the
> current run, which is located in the dictionary type object
> 'self.relax.data[]', could be aliased as say 'data_pipe' or
> 'current_pipe' and placed into '__builtin__'. Then any part of relax
> can access the data of the current data pipe by referring directly to
> 'current_pipe'. Maybe a better variable name would be 'cdp' (current
> data pipe)? Or maybe simply 'data'?
> In addition, I don't believe the name 'run' encapsulates the concept
> at all. This name is a relic which is not at all related to its
> current use (https://mail.gna.org/public/relax-devel/2006-10/msg00056.html,
> Message-id:
<1160555137.9523.70.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>).
> The current use of the name 'run' encapsulates the segregation of the
> data. This is why I prefer the words 'data pipe' or 'pipe' over
> 'run'.
>
I wasn't trying to express an opinion over where or how the current run
object is stored or aliased or even over what it is called. I simply
wanted to say that within the relax code, we should address the run as
an object, not as a string that serves as key to the dictionary of runs.
(I had to adopt a position on names, locations, etc only in a vain
attempt to avoid my arguments becoming intractably abstract)
If we alias the current run (data pipe) as 'cdp' into '__builtin__',
then 'cdp' throughout relax would access the data pipe data structure
object. The string is used by the user when necessary in the UI
whereas the developer uses the aliased object behind the scenes.
ie. current_pipe should be the current pipe, not the name of the current
pipe, whether current_pipe is an attribute of __builtin__ or of
self.relax.data or of any other class we care to nominate.
That's what I meant.
On the other hand, I think we agree that the user command pipe.current()
should return the name of the current pipe, and similarly all user
commands should address runs with run names.
Agreed :)
If I were to express an opinion on the question of the appropriate name
for the 'run' idea, I would have to say that pipe is better than run,
but still not ideal. Essentially because the idea of a run/pipe in relax
is actually quite different to the pipe idea exemplified by nmrPipe, eg.
The better metaphor might be of the production line, but
current_production_line will quickly become unwieldy!!
I like the production line analogy. Maybe there are some avenues
there for finding another name which is a little shorter? If we can't
find an alternative simple yet descriptive noun, we could refer to the
pipe in the docstrings, documentation, etc. as 'data pipes'. Then
this is easily differentiable from the well known Unix pipes of
nmrPipe.
> pipe.switch(pipe_name):
> __builtin__.current_pipe = self.relax.data[pipe_name]
>
>
> > run.current():
> > return self.relax.data.run.name
>
> pipe.current():
> return current_pipe.name
>
> Having the name stored in the dictionary as a key and in the data pipe
> container as the 'name' variable is a little redundant. Maybe the
> current pipe name should be stored as say 'self.relax.current_pipe'?
I like the clarity of having an attribute for name. In fact in other
contexts I have coded a sub-class of dictionary which automates this
process so there can never be a conflict between the key and the 'name'.
Something like:
class NamedDict(dict):
def __setitem__(self, key, val):
dict.__setitem__(self, key, val)
self[key].name = key
That's a much better way of doing it. If we ever implement a user
function such as 'pipe.rename()', then we need to remember to modify
other functions.
Cheers,
Edward
Re: Redesign of the relax data model: 2. A new run concept