Keren Lasker wrote:
> yes - I just was not sure where we draw the line between stuff that
> should be helper vs. in modules.
helper is also a module - it's just a higher level interface. So
something general that pulls in functionality from several classes
(possibly in several modules) could go there. But something that is
obviously EM-related should live in IMP.em.
> I think that Daniel meant for the modules to have just a very basic
> functionality, although I agree that rigid fitting should go in EM.
Well, it depends whether you define "rigid fitting" as "fitting into an
EM density map" (in which case it lives in IMP.em) or "fitting into some
kind of map" (in which case maybe it should go in a separate module).
> I guess that the decision would be on a case-to-case basis, for example
> flexible fitting should probably go directly to application and not to em.
Perhaps. It is always possible to refactor and move things out of an
application into a module if we really want to be able to use them
elsewhere, of course.
Ben
--
http://salilab.org/~ben/
"It is a capital mistake to theorize before one has data."
- Sir Arthur Conan Doyle