Hi,
Yes, the generic_fns package and specific_fns package do operate
completely differently. What I am trying to do with the 1.3 line is
to make a clear API for the specific functions so that when someone
adds a new type of analysis to relax, they just need to provide a few
class methods in 'specific_fns' to get certain user functions
operational. Note that all the code in 'specific_fns' is object
oriented being located in class methods. This design is being used
because each class specific to an analysis inherits a set of common
methods from 'specific_fns.base_class.Common_functions'. Inheritance
is heavily used in 'specific_fns'.
On the other hand, the 'generic_fns' code is shifting to something
quite different. I'm moving away from object oriented code here and
shifting everything into a module design. All the old class methods
are being converted into module functions, hence the classes are being
eliminated. The reason for this change is that there is no advantage
in having classes as there is no inheritance and no permanent data
storage in this code. But do note that there will be a few classes
used to create objects, such as Chris MacRaild's heavily used
'Selection' object.
So in the 'prompt' package code, you will see two differences. The
generic code will be accessed like:
-----
from generic_fns import sequence
...
# Execute the functional code.
sequence.display(...)
-----
This is because the package is called 'generic_fns', the module is
called 'sequence', and the function is called 'display'. On the other
hand, the specific code will be accessed (much less commonly though)
like:
-----
from specific_fns.setup import model_free_obj
...
# Execute the functional code.
model_free_obj.select_model(model=model, spin_id=spin_id)
-----
So the instantiated class 'model_free_obj' is being imported from
'specific_fns.setup' where the class was instantiated. This way of
handling 'specific_fns' is very ugly, and I'm sure this will change in
the future when a better approach can be found. Nevertheless, the two
packages will be handled quite differently.
Cheers,
Edward
On Thu, Apr 3, 2008 at 11:16 PM, Sébastien Morin
<sebastien.morin.1@xxxxxxxxx> wrote:
Hi,
I just noticed I've been instantiating many classes in the prompt/
directory. However, the classes from the generic_fns/ directory are not
yet set-up has those in the specific_fns/ directory.
Should these classes from the generic_fns/ directory be instantiated ?
Should I create a setup file in the generic_fns/ directory as in the
specific_fns/ directory ?
Thanks for the cue !
Séb :)
_______________________________________________
relax (http://nmr-relax.com)
This is the relax-devel mailing list
relax-devel@xxxxxxx
To unsubscribe from this list, get a password
reminder, or change your subscription options,
visit the list information page at
https://mail.gna.org/listinfo/relax-devel
Re: Classes instantiation