[Bioperl-l] Annotation proposal

[Matthew Pocock]

Ewan Birney wrote:

> On Tue, 10 Apr 2001, Matthew Pocock wrote:
> 
> 
>> Ewan Birney wrote:
> Re: your frame stuff/code snippets.
> 
> Frankly it just *scares me* what you can do with Perl AUTOLOAD, a
> little bit of closure/anonymous subroutines and a hash. Is this sane?
> 

Closures are very powerful, and in my view should be used wherever you 
want run-time implementations without exposing the actual implementation 
or creating yet one more module e.g. iterator objects. Perl is not the 
only language to have a 'do this if you don't know what to do' method. I 
think to save yourself from debugging hell, you realy have to also hide 
CAN and probably ISA so that the objects realy do subscribe to the 
interface that they implement, but this is no big deal.

> 
> But basically you are right - I think we do want some type-safe system but
> run-time resolved mix-in something-or-other, aka Frames aka whatever other
> buzzword you want to put in it. What is the best way to allow this to
> happen? How constrained should it be by compile time language constraints?

This is realy more of an object-oriented lisp thing to do. The perl 
run-time works prety much identicaly to how my FluffyObject things do 
except that the methods hash is a symbol table bound to a package which 
also stores package-scoped variables. If you think of what you can do 
with javascript (add methods to objects as you instantiate them), or 
what you get by instantiating anonymous inner classes in Java, this is 
realy not that different. The no-1 key is that no data is exposed - all 
data access goes though methods. '42' is a function that evaluates to 
the integer 42 etc.

It all becomes much more usefull when I can have an interface defining 
foo & bar (either as a fluffy object or as a normal perl package), and 
then create a fluffy object that says it implements that interface and 
have ISA work correctly. It becomes much more useful if you can easily 
introspect the available methods (try the $obj->METHODS funciton). At 
that point, I don't think there is any danger in creating run-time 
types. Is there a utility? Probably there is for creating object 
representations of complex ontologies. It does allow fluffy and hard 
objects to be mixed together. If you have a propper query language then 
these graphs of fluffies and hards can be data-mined by fairly generic 
routines and then we can move into a new era of knowledge discovery (OK 
- a bit carried away here).

Anyway, I'm going back to Java where this sort of thing is more tricky 
to do (because Sun cocked up the Class and ClassLoader objects) but 
works out if everything is a bean and you happen to have a byte-code 
generator lying arround.

Matthew

;-)