[Bioperl-l] prototype objects for mapping and MapIO

[Chad Matsalla]

OK, I have committed the following modules as prototypes for how a linkage
map containing microsatellites might be represented using Bio::Map::* :

Bio::Map::OrderedPositionWithDistance
Bio::Map::LinkagePosition
Bio::Map::LinkageMap
Bio::Map::Microsatellite
Bio::Map::Mapmaker
Bio::Map::Marker

I realize that these will need to be put in their appropriate places and
things like that so I'm not worried if they need to be
redone/relocated/discarded or whatever. They are also a bit rough because
I wan't sure what would work and what wouldn't so I commit them with the
below outlines of my thoughts for comment.

Bio::Map::Mapmaker is my prototype of a file-to-map mechanism of building
a certain kind of map containing a certain type of marker from a file.

Bio::Map::Mapmaker is a parser for a Mapmaker datafile like this:
<snip>
13> map
===============================================================================
Map:
  Markers          Distance
    1  chad1         0.0 cM
    2  chad2         0.0 cM
    3  chad3         3.3 cM
    4  chad4        10.1 cM
    5  chad5         6.7 cM
    6  chad6        13.7 cM
    7  chad7        10.1 cM
<snip>

I know that it should go into a MapIO type of mechanism but I wanted a
quick prototype. I hooked it up to produce a LinkageMap of Microsatellite
objects. To see what that gives, check out t/mapmaker.t.


When a member of the MapIO subsystem parses a marker, it should not care
what kind of marker it is. Thus, I implemented a Marker.pm (as opposed to
a MarkerI.pm) that has a new() method that takes, at the minimum, a name
and LocationI-compliant object. I didn't enforce the identity of the thing
passed in as the LocationI-compliant object though.

In my view of the MapIO subsystem, calling next_marker() will result in
the creation of a generic marker with a generic location. This marker will
be passed back to the caller who can then cast (rebless) the marker into
the specific type (in this case, a Microsatellite) so that additional
characteristics can be added to it.

I also added a position() method to Position.pm. It needed it.

I created a OrderedPositionWithDistance.pm . In my thinking, the MapIO
subsystem requires a slightly less generic PositionI-compliant object to
recurd distance and in the case of these linkage maps order is also
important. I created OrderedPositionWithDistance.pm after LinkagePosition
but in my thinking the caller could not only bless markers returned by the
MapIO subsystem into the proper marker class but also bless the marker's
Location into the proper Location class.

Because really, only the caller should care about the type of Marker and
Location is being returned. Well, the parser should know what kind
of generic object to create as well.

Also, I think that there should be a print_map in MapI. This should be
implemented in child modules to print out a representation of the map to
the screen. Much easier then using Data::Dumper or dumpvar.pl.

In that line, why should there not be a 'print_object' or 'out' method in
_all_ modules? Don't most other languages like developers to put a .out
method in classes for debugging?

I use /usr/local/lib/perl5/$PERL_VERSION/dumpvar.pl and have had some
discussions with other people about the need to 'require' it in my
modules. If modules had 'print_module' methods the debugging tools would
be there by default. Nice!

Hope somebody has comments on this. I think I'll stop for a while until
somebody looks at it.

Chad Matsalla