[Bioperl-l] Bio::FeatureHolderI interface confusion

Matthew Pocock matthew_pocock at yahoo.co.uk
Fri Jun 20 16:33:49 EDT 2003

Personaly, I would go with throws and eval every time. Usualy, I find 
that rather than wrapping /every/ get/set with an eval, you end up 
wrapping up each transaction in an eval block. This usualy contains 
several operations that may fail, and you then get a chance at the end 
to clean up after, retry, or give up on that transaction. You can always 
forward the error on if needs be. As Hilmar says, for throw-away 
scripts, you don't want to handle these cases anyway.

As for the mutable vs immutable interface argument, having mutable 
interfaces at least doubles your number of interfaces. You end up with a 
parallel tree of mutables to the immutables which is awquard to maintain 
and confusing. Also, in many cases an implementation may only be able to 
implement part of the mutability contract e.g. a feature that can set 
the source & type, but not the location, or can set all local properties 
but not edit children, or edit children but not local properties. Nasty 
badness. But, some people have strong objections to making the basic 
interfaces for data objects mutable. Not entirely sure why.


Hilmar Lapp wrote:
> Imagine you'd have to wrap every setter in bioperl with this. My point 
> is that from a practical viewpoint it is very rare that you only want to 
> warn if the object doesn't permit set. In most cases, that will destroy 
> your business logic and hence bailing out with an uncaught exception is 
> appropriate.

>     -hilmar

More information about the Bioperl-l mailing list