[Biojava-dev] Where BioJava3 is going
LAW Andrew
andy.law at roslin.ed.ac.uk
Thu May 20 09:55:57 UTC 2010
Interface is no use to me if I want the coordinate transformation goodness. That requires real active code.
My ideal design has Interface (good for coding and testing), underpinned by Bean-style Implementation (good for shared common code actually implementing the functionality) underpinned subsequently by a third package of data access implementation. You can build your third layer, I can build mine but we can all leverage off layers 1 and 2.
On 20 May 2010, at 10:44, Andy Yates wrote:
> If someone is going to use the interface & code then it's got to be 1:1 IMHO. Glue code is fine for existing APIs but not for new ones :)
>
> On 20 May 2010, at 10:42, Mark Schreiber wrote:
>
>> If the interface doesn't quite fit you could build some bridge
>> conversion code, although this takes you further from BioJava3 and
>> makes it's use more questionable for your purpose.
>>
>> - Mark
>>
>> On Thu, May 20, 2010 at 5:38 PM, Andy Yates <ayates at ebi.ac.uk> wrote:
>>> That's got to be the way to go but the interface needs to be slightly more flexible WRT to features & attributes. Currently Sequence defines just that where as Sequence would really be used as the container for compounds & "other things". If that's in place then hopefully this will help the guys at the Roslin to do what they need to do
>>>
>>> Andy
>>>
>>> On 20 May 2010, at 09:59, Mark Schreiber wrote:
>>>
>>>> Any reason why we couldn't have a maven module where Sequence<C
>>>> extends Compound> interface goodness is backed by an Ensembl mapping
>>>> beany implementation? This would seem to me to be the best approach.
>>>> That way if you want to use Ensembl and BioJava you could just drop in
>>>> the appropriate module.
>>>>
>>>> - Mark
>>>>
>>>> On Thu, May 20, 2010 at 4:53 PM, Andy Yates <ayates at ebi.ac.uk> wrote:
>>>>> Changed the subject to something more relevant.
>>>>>
>>>>> I think this is more exemplified by the current state of the API rather than the intention of where it can go. Scooter's main focus is working towards solid objects to represent entities on Sequence e.g. GeneSequence/ChromosomeSequence are perfect examples of this. My focus is more towards working at the generic level so more programming against Sequence<C extends Compound> interfaces; translation, reversing & complementing strongly points towards this. Between us though I really do hope we can generate a framework which lets a user come in and use the more solid classes but also let another API use the backing classes.
>>>>>
>>>>> The rest will be coming soon. I am also looking at supporting features and attributes against Sequences but this is still some time off. I'm also looking at coordinate translation but again this is something that is sometime away (mostly because I do not have the test case to do it).
>>>>>
>>>>> The enemy here is time as I am sure it is for your group.
>>>>>
>>>>> Probably the best thing I can do is put up some design documents onto the wiki about where I think parts of the API should go and people can pick this to pieces as much as they want to. Interfaces and test cases about intended behaviour would also help. Again this will take time :(
>>>>>
>>>>> Andy
>>>>>
>>>>> On 20 May 2010, at 09:30, LAW Andrew wrote:
>>>>>
>>>>>>
>>>>>> On 20 May 2010, at 05:11, Mark Schreiber wrote:
>>>>>>
>>>>>>> If you are using BioJava objects as fake DTO's or EntityBean
>>>>>>> look-a-likes you should really question why you are using BioJava
>>>>>>> objects in the first place. Not sure what BioJava3 objects will look
>>>>>>> like but BJ1.X objects are definitely not good at this.
>>>>>>>
>>>>>>> It also raises and interesting point which I haven't seen discussed
>>>>>>> much on the list; what will BJ3 be for (or not for). One of the
>>>>>>> painful lessons (for me) from working on BioJava is you can't make an
>>>>>>> API do everything. The more modular approach to BJ3 should help avoid
>>>>>>> this. I see nothing wrong with having a module that is more suitable
>>>>>>> for the kind of work sequence-data-binding you are proposing. This
>>>>>>> modules objects should definitely have public constructors and public
>>>>>>> setters. Why not make use of Entity Beans (Post EJB 3) while your at
>>>>>>> it. If it is in it's own module it will not corrupt the other parts of
>>>>>>> BioJava with "unsafe" beany objects.
>>>>>>>
>>>>>>> In this case making your own objects (and sharing them) would actually
>>>>>>> be a whole lot better than trying to shoe horn an API that wasn't made
>>>>>>> for this. Some IDEs will even auto-generate databinding objects for
>>>>>>> you; although, I understand there is some strange cases in Ensembl
>>>>>>> that might not make this a good idea).
>>>>>>
>>>>>>
>>>>>> I think this is really the point that we have been picking at all along. The current way that BJ3 objects seem to be set up makes them difficult to use in any manner other than that intended by the core BJ3 developers. We were hoping that there would be all the generic sequence and coordinate transformation "goodness" available for us in a bean format and then all we would have to do (!!) would be to define the data access methods necessary to populate those objects. That seems to be not the way that things are set up and mapping our ideas and thought processes to BJ3 has not been as easy as we would have liked.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Later,
>>>>>>
>>>>>> Andy
>>>>>> --------
>>>>>> Yada, yada, yada...
>>>>>>
>>>>>> The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336
>>>>>> Disclaimer: This e-mail and any attachments are confidential and intended solely for the use of the recipient(s) to whom they are addressed. If you have received it in error, please destroy all copies and inform the sender.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> The University of Edinburgh is a charitable body, registered in
>>>>>> Scotland, with registration number SC005336.
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> biojava-dev mailing list
>>>>>> biojava-dev at lists.open-bio.org
>>>>>> http://lists.open-bio.org/mailman/listinfo/biojava-dev
>>>>>
>>>>> --
>>>>> Andrew Yates Ensembl Genomes Engineer
>>>>> EMBL-EBI Tel: +44-(0)1223-492538
>>>>> Wellcome Trust Genome Campus Fax: +44-(0)1223-494468
>>>>> Cambridge CB10 1SD, UK http://www.ensemblgenomes.org/
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>> --
>>> Andrew Yates Ensembl Genomes Engineer
>>> EMBL-EBI Tel: +44-(0)1223-492538
>>> Wellcome Trust Genome Campus Fax: +44-(0)1223-494468
>>> Cambridge CB10 1SD, UK http://www.ensemblgenomes.org/
>>>
>>>
>>>
>>>
>>>
>
> --
> Andrew Yates Ensembl Genomes Engineer
> EMBL-EBI Tel: +44-(0)1223-492538
> Wellcome Trust Genome Campus Fax: +44-(0)1223-494468
> Cambridge CB10 1SD, UK http://www.ensemblgenomes.org/
>
>
>
>
Later,
Andy
--------
Yada, yada, yada...
The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336
Disclaimer: This e-mail and any attachments are confidential and intended solely for the use of the recipient(s) to whom they are addressed. If you have received it in error, please destroy all copies and inform the sender.
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
More information about the biojava-dev
mailing list