Hi Ian,
On Wed, Jun 22, 2011 at 9:11 AM, Ian Turton <ijtur...@gmail.com> wrote:
> It looks good to me so +1.
>
> My small niggle is the use of
>
> query.getJoins().add(join1);
>
> where I might prefer:
>
> query.addJoin(join1);
>
> which might be easier for users to spot in the API.
>
I don't have a strong preference but I tend to stay away from doing that in
apis and instead just make the collection available. Reasoning being that
you are start to have to turn the containing class (in this case Query) into
a collection type, give it a getNumberJoins() method, removeJoin(), etc...
which imo pollutes the api.
>
> If you do stick with getJoins() is there are there good reasons to
> make it return a list over a collection? I can't work out if it is
> important to force an ordering to joins or not.
>
I do think ordering is important, if for anything to determine what order
the attributes will be in the resulting feature type. It would seem strange
to do:
query.getJoins().add(new Join("type1"))
query.getJoins().add(new Join("type2"))
But then have the feature type return them in the order "type2", "type1". So
I guess my answer would be "any reason not to make it a list"? :)
>
> Ian
> --
> Ian Turton
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
