Round-up

[Steven E. Brenner]

[Note: for some people, this may be a re-send]

Hi folks,

  Congratulations on the great job with the OiB electronic poster.  I
think you guys did a great job of putting that together.

  Sorry for being away for so long -- just after my conference to China, I
had to give a series of talks and also ended up going on two extended
sightseeing trips (to see parts of Japan before I depart in 2 weeks).  I
have read through all of the mail messages, and see the following issues
as probably still being relevant.  (Please let me know if I missed any!)

1)  Accesor names.  My weak preference (actually taken from C++) is for
having a single function which both sets and retrieves information.  As
Georg explained, using a special tag for undefined (I would have chosen
"_undef", but made this setable via a package-global function), this is
possible to do.  If they are going to be split, I prefer seq()/setseq()
rather than getseq()/setseq(), at least for simple operations.

  I don't think we need to be totally consistent.  For "complex" features,
get/set is ok with me.  (e.g, get_residue_numbering_by_identifier), but
for simple and very common operations fewer characters are a benefit if
clarity can be maintained.

  Though it hasn't been proposed, I should mention that I don't like
"synonyms" -- we should avoid having multiple functions for the same
operation. 

2)  GenericAbstractParentIterator

Peter Murray-Rust is wrong: I have used both Keith Robison's and Phil
Bourne's C++ code (though I may be the only one).  I've also written my
own for handling structures (which only a handful of people have used). 
>From my experience, the problems were twofold:
  a)  Getting C++ code to compile on different machines or compilers
is a pain.  C++ simply remains too poorly standardized and implemented
  b)  The learning curve is considerable, especially with various gotcha's
regarding pointers and memory allocaiton

Extreme abstraction was not the principal problem.  So long as the modules
are intuitive and convenint, I think that the design behind them will
not reduce their use by the community.

I think that the modules currently being developed meet the criteria of
intitiveness and convenience.  (Though I wonder whether we can do the same
for structures.)


3)  Releasing these darn things finally!!

Background info: the bioperl list at mole is now gone; the sysadmin
removed it because of junk mail it was attracting. 

Georg and Chris - What do you want me to do?

I think that if we release the code on CPAN it has to build and install
"out of the box."  If people have to do fiddling, then they'll think it is
fiddly software which will be complex to use.  The last thing we want to
do is turn people off before they even install the code!

Tell me how to act


4)  A bioperl meeting

Fine with me!  I would propose at Stanford (since both Steve's will be
there), though Cambridge, MA might also be do-able.  Early December or
late January seem to be good dates to allow enough time and avoid
conflicts with other meetings if it is going to be quite small.  If we
want to invite more people, then it should be pushed off further.

How should we move ahead with this?

If there are other issues I didn't address, please let me know.

Steve

P.S.  Yes, I'm going to be disappearing again soon.  From 9 July - 1
August, I will be "in transit," though I should have email access for two
weeks in the middle while I'm visiting a laboratory in Singapore.  From
August, I will be at Stanford, but I will be away from 3-21 September,
during which I should also have some email access .