[Biojava-dev] bjv2 alpha 3

[mark.schreiber at group.novartis.com]

Hey! I prefer to think of myself as a lazy drag n dropper than a dumb drag 
n dropper :)

But serioulsy, there are other good reasons to have a beany version of 
things. Interoperability with JAXB and other bean centric APIs springs to 
mind. Threre are lots of cool things that can be done with beans and 
reflection all of which happily violate the principle of encapsulation and 
are quasi illegal but are cool none the less.





Matthew Pocock <matthew_pocock at yahoo.co.uk>
Sent by: biojava-dev-bounces at portal.open-bio.org
05/24/2004 09:02 PM

 
        To:     Mark Schreiber/GP/Novartis at PH
        cc:     biojava-dev-bounces at portal.open-bio.org, Biojava-dev 
<biojava-dev at biojava.org>, Michael Heuer <heuermh at acm.org>
        Subject:        Re: [Biojava-dev] bjv2 alpha 3


Queue brain-dump... Utility methods are primarily intended for dumb 
users - dumb coder users. A different mechanism may be more appropreate 
for dumb drag-n-droppers. I am assuming from what you have said that 
bean editors let you do quasi-illegal things like invoking static 
methods relative to instances. I've no problem with 'skinning' bjv2 for 
a different user group. What if we had some magic like this:

Object tool = new ToolFactory().makeTool(Utility.class)

This returns a 1st class object with non-static methods that alias to 
the static tools methods on Utility.class and is serializable - would 
this help?

What's the standard pattern for exposing processes through beans? I'd 
feel much happier if this level of logic was handled in a workflow 
language e.g. Taverna could be adapted so that all utility classes 
become processors. That way dumb d-n-d users realy don't have to look at 
any of the code.

>It would be nice if more of BioJava could be made into valid beans. 
>Unfortunately this does render all of the elegant singletons invalid. If 
>only java had a keyword for a constructor that could be called only by 
the 
>VM to create a bean. I suspect such a thing would cause all kinds of 
>security problems though.
>
>- Mark
>
>
>_______________________________________________
>biojava-dev mailing list
>biojava-dev at biojava.org
>http://biojava.org/mailman/listinfo/biojava-dev
>
> 
>

_______________________________________________
biojava-dev mailing list
biojava-dev at biojava.org
http://biojava.org/mailman/listinfo/biojava-dev