We now have several different layers of functionality in IMP, which are kind of jumbled together in core. For example, with rigid bodies, you can create one by - decorating a particles - creating a couple of score states from relatively general purpose singleton modifiers and container based score states - adding them to the model or - use a create_rigid_body function to do it all for you
Having all of these together clutters the documentation and makes it harder to find out what you should be doing. That said, we need at least some of the detail bit available to users, so we can't really hide them away as internal.
One option would be to pull these into their own module (I can't think of the right name offhand, perhaps helpers), and reserve core for very general purpose things like PairsRestraint.
Not sure what other options are.
Since I think such a new module is a good idea, I'll make it more concrete. Let's have a new module called IMP.helper. Its primary purpose is to contain functions that perform common tasks that - involve creation of more than one restraint or score state - creation of a restraint or score state followed by non-trivial manipulation of it - functions to create standard particle sets
Examples would include existing code such as: - creating a rigid body and associated score states - restraining the diameter of a set of particles - creating a hard sphere excluded volume restraint which intelligently handles rigid bodies - creating a coarse grained model of a protein with known number of amino acids, but no known structure
Having it in a module means that there is a clear first place to look for such things. The low level functionality in core is clearly differentiated from functions that use it.
On Fri, May 15, 2009 at 1:46 PM, Daniel Russel drussel@gmail.com wrote:
> We now have several different layers of functionality in IMP, which are > kind of jumbled together in core. For example, with rigid bodies, you can > create one by > - decorating a particles > - creating a couple of score states from relatively general purpose > singleton modifiers and container based score states > - adding them to the model > or > - use a create_rigid_body function to do it all for you > > Having all of these together clutters the documentation and makes it harder > to find out what you should be doing. That said, we need at least some of > the detail bit available to users, so we can't really hide them away as > internal. > > One option would be to pull these into their own module (I can't think of > the right name offhand, perhaps helpers), and reserve core for very general > purpose things like PairsRestraint. > > Not sure what other options are. >
Daniel Russel wrote: > Since I think such a new module is a good idea, I'll make it more > concrete. Let's have a new module called IMP.helper. Its primary purpose > is to contain functions that perform common tasks that > - involve creation of more than one restraint or score state > - creation of a restraint or score state followed by non-trivial > manipulation of it > - functions to create standard particle sets > > Examples would include existing code such as: > - creating a rigid body and associated score states > - restraining the diameter of a set of particles > - creating a hard sphere excluded volume restraint which intelligently > handles rigid bodies > - creating a coarse grained model of a protein with known number of > amino acids, but no known structure > > Having it in a module means that there is a clear first place to look > for such things. The low level functionality in core is clearly > differentiated from functions that use it.
I completely agree that a separate module is the best place for such functionality. I'm just not sure I like the name. ;) Can't think of a better one though...
Ben
On Mon, May 18, 2009 at 2:51 PM, Ben Webb ben@salilab.org wrote:
> Daniel Russel wrote: > > Since I think such a new module is a good idea, I'll make it more > > concrete. Let's have a new module called IMP.helper. Its primary purpose > > is to contain functions that perform common tasks that > > - involve creation of more than one restraint or score state > > - creation of a restraint or score state followed by non-trivial > > manipulation of it > > - functions to create standard particle sets > > > > Examples would include existing code such as: > > - creating a rigid body and associated score states > > - restraining the diameter of a set of particles > > - creating a hard sphere excluded volume restraint which intelligently > > handles rigid bodies > > - creating a coarse grained model of a protein with known number of > > amino acids, but no known structure > > > > Having it in a module means that there is a clear first place to look > > for such things. The low level functionality in core is clearly > > differentiated from functions that use it. > > I completely agree that a separate module is the best place for such > functionality. I'm just not sure I like the name. ;) Can't think of a > better one though...
Same here :-)
common_tasks ?
2009/5/18 Daniel Russel drussel@gmail.com
> > > On Mon, May 18, 2009 at 2:51 PM, Ben Webb ben@salilab.org wrote: > >> Daniel Russel wrote: >> > Since I think such a new module is a good idea, I'll make it more >> > concrete. Let's have a new module called IMP.helper. Its primary purpose >> > is to contain functions that perform common tasks that >> > - involve creation of more than one restraint or score state >> > - creation of a restraint or score state followed by non-trivial >> > manipulation of it >> > - functions to create standard particle sets >> > >> > Examples would include existing code such as: >> > - creating a rigid body and associated score states >> > - restraining the diameter of a set of particles >> > - creating a hard sphere excluded volume restraint which intelligently >> > handles rigid bodies >> > - creating a coarse grained model of a protein with known number of >> > amino acids, but no known structure >> > >> > Having it in a module means that there is a clear first place to look >> > for such things. The low level functionality in core is clearly >> > differentiated from functions that use it. >> >> I completely agree that a separate module is the best place for such >> functionality. I'm just not sure I like the name. ;) Can't think of a >> better one though... > > Same here :-) > > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev > >
Javier Ángel Velázquez Muriel wrote: > common_tasks ?
I would prefer to avoid underscores in module names if we can, since 1) shorter names are quicker to type and 2) each IMP module is a corresponding Python package, and underscores are discouraged in Python package names. So "helper" is better, IMHO.
Ben
Well, lets go with "helper" for now since no one has come up with anything better. Changing a module name isn't that big a deal if someone receives a brilliant insight :-)
On Wed, May 20, 2009 at 12:48 PM, Ben Webb ben@salilab.org wrote:
> Javier Ángel Velázquez Muriel wrote: > > common_tasks ? > > I would prefer to avoid underscores in module names if we can, since 1) > shorter names are quicker to type and 2) each IMP module is a > corresponding Python package, and underscores are discouraged in Python > package names. So "helper" is better, IMHO. > > Ben > -- > ben@salilab.org http://salilab.org/~ben/http://salilab.org/%7Eben/ > "It is a capital mistake to theorize before one has data." > - Sir Arthur Conan Doyle > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev >
participants (3)
-
Ben Webb -
Daniel Russel -
Javier Ángel Velázquez Muriel