Moving container-related code to its own module
I'm proposing moving the container-related code out of core into their own module. This is something I'd thought about when I first implemented them, but had decided not to, without any strong reason. The reasons for wanting to do this now are: - they form a well defined collection of functionality that can be best explained together - the list of functionality in core is very long and hard to one's head around - core is huge, takes forever to compile
Affected classes would be List*Container, *ContainerSet, AllPairContainer and kin and ClosePairContainer and kin. I think few people use the classes directly currently, other than to create ListSingletonContainers, so there would not be too many changes.
Thoughts? Objections?
great idea! it is indeed hard to find them in core.
On Fri, Feb 12, 2010 at 11:21 AM, Daniel Russel drussel@gmail.com wrote: > I'm proposing moving the container-related code out of core into their own module. This is something I'd thought about when I first implemented them, but had decided not to, without any strong reason. The reasons for wanting to do this now are: > - they form a well defined collection of functionality that can be best explained together > - the list of functionality in core is very long and hard to one's head around > - core is huge, takes forever to compile > > Affected classes would be List*Container, *ContainerSet, AllPairContainer and kin and ClosePairContainer and kin. I think few people use the classes directly currently, other than to create ListSingletonContainers, so there would not be too many changes. > > Thoughts? Objections? > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev >
On 02/12/2010 11:21 AM, Daniel Russel wrote: > I'm proposing moving the container-related code out of core into > their own module. This is something I'd thought about when I first > implemented them, but had decided not to, without any strong reason.
Sounds reasonable to me. My only concern is that the close pair stuff is going to require a lot of things to be moved around, but I'm sure you thought of that already.
Ben
participants (3)
-
Ben Webb
-
Daniel Russel
-
Dina Schneidman