[Biojava-l] Re: the current discussion

[Matthew Pocock]

Hi.

Mark Schreiber wrote:

> <snip/>
> > My code is not yet javadoc'd.  And won't be before next weekend.  But you
> > can have a look at a UML diagram of my protein classes.  It communicates a
> > lot.
>
> Prehaps as a standard all classes should have atleast javadoc or better,
> what do others think?

My rules of thumb are:

If it is an interface, it must have JavaDoc for the interface & for each method
that make it prety hard to mis-interpret what is going on.

If it is a class that implements an interface then it may only need
documentation for the class to say something about the implementation. Any
method that implements an ambiguous part of the interface (e.g. one that throws
UnsupportedOperationException, or any other leaway alowed by the interface)
should be documented. Documentation inheritance can be used for the rest.

If a class is a fully functoning object in it's own right (like a singleton or
some othe resource, or some concept that doesn't have an interface) then it
should be documented fully.

>
> >
> > On GUIS:  agree with most of what's been said.  Should definitely keep the
> > GUI isolated from the implementation of the model, in accordance with
> > Model-View-Contoller paradigm
> >
> >
>
> I agree completely. But if people can design GUI's that can easily be used
> with several packages or that fit really well with a package I think they
> would be great. Things like a sequence viewer could fit with many
> implementations of a sequence class. Also for those interested in HMMs I
> have often thought it would be great to have a GUI that lets you perform
> model surgery graphically. (Oh to have the time!)
>

Ah - I have HMM stuff in the package bio.alignment, and I have written a GUI for
visualizing models. It is only a hop-skip-and-a-jump from being an HMM editor.

> <snip/>
> This maybe a matter of person utility. For my work I have no need at the
> moment for anything other than strings however those doing protein
> modelling will benefit more from Mikes strategy. Lets have both! and
> why not have some kind of class to convert between the two.

We use objects for several very good reasons like an A in DNA is distinct from
an A in a protein - they are seperate objects with no overlap in meening, and
are both seperate objects from state A in an HMM. Also, we can model things like
protein phosphorylation naturaly by putting in a phospho-aa object that can
print itself out as the normal character if needed or can behave in special ways
if you want it to - no extra memory cost to having phosphorylation information
in a proten (except a slightly expanded protein alphabet).

Our sequences have  a simple method to retrieve the sequence as a string of
chars where each char represents a single residue. Also, as everything is
implemented on top of interfaces, you could write an implementation that realy
did use a string of chars to represent the sequence, as long as you wired in
apropreate residueAt and iterator methods.

Having residue objects catches loads of errors that would go unnoticed
otherwise. Also, for HMMs, each state within the model is a State object that
extends Residue, so you can naturaly manipulate sequences of states. This is
realy usefull - a multiple-sequece-aligment can contain sequences and states.
But - as states are not defined by chars, we can make virtual states with no
sensible way of naiming them.

Anyway, I guess what i am saying is that you can have your cake and eat it with
this one - once hotspot has got its teeth in - and the code you end up with
looks almost identical to using chars, but it is type-checked and behaves oopy,
not stringy.

Matthew

>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Mark Schreiber                  Ph: 64 3 4797875
> Rm 218                          email mark_s@sanger.otago.ac.nz
> Department of Biochemistry      email m.schreiber@clear.net.nz
> University of Otago
> PO Box 56
> Dunedin
> New Zealand
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> _______________________________________________
> Biojava-l mailing list  -  Biojava-l@biojava.org
> http://biojava.org/mailman/listinfo/biojava-l