[Engine-devel] Use java.util.Collection where possible?
Danny Rankevich
danny.ran at redhat.com
Thu Mar 15 17:52:47 UTC 2012
I ran deRPC with Collection in the parameters AND return type, and everything works ok.
why should there be a problem? the concrete type is serialized in the payload...
----- Original Message -----
> From: "Asaf Shakarchi" <ashakarc at redhat.com>
> To: "Danny Rankevich" <danny.ran at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "Yair Zaslavsky" <yzaslavs at redhat.com>
> Sent: Wednesday, March 14, 2012 1:19:18 PM
> Subject: Re: [Engine-devel] Use java.util.Collection where possible?
>
> Danny are you sure?
> IIRC GWT RPC Oracle wont be able to pick the right implementation
> and will generate code for any possible concrete impl,
>
>
> Asaf.
> ----- Original Message -----
> > From: "Danny Rankevich" <danny.ran at redhat.com>
> > To: "Yair Zaslavsky" <yzaslavs at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Wednesday, March 14, 2012 12:58:35 PM
> > Subject: Re: [Engine-devel] Use java.util.Collection where
> > possible?
> >
> > BWT I did some checks on the GWT RPC that we use (deRPC) and there
> > shouldn't be any problems using Collection interface (or any
> > interface) in the generic api service.
> >
> > ----- Original Message -----
> > > From: "Allon Mureinik" <amureini at redhat.com>
> > > To: "Yair Zaslavsky" <yzaslavs at redhat.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Sunday, March 4, 2012 6:57:24 PM
> > > Subject: Re: [Engine-devel] Use java.util.Collection where
> > > possible?
> > >
> > > My two cents:
> > >
> > > There are two meanings of subtyping Collection (or any other
> > > interface, for that matter) - additional logic and specific
> > > implementation.
> > > I think wherever possible, we should use the interface that
> > > infers
> > > as
> > > much logic as possible (e.g., java.util.List for ordering,
> > > java.util.Set for uniquness, java.util.SortedSet for natural
> > > ordering, etc.), without inferring any specific implementation
> > > (e.g., ArrayList, HashSet, etc.).
> > >
> > > The flipside of this notion is that it's a mistake to use an
> > > overly
> > > specific class/interface - when your parameter type is ArrayList,
> > > you implicitly tell the user the *order* of his objects matter,
> > > and
> > > that it matters to your internal algorithm to be able to do
> > > get(i)
> > > as an O(1) operation.
> > >
> > > Bottom line, now that I'm done with CS 101:
> > > +1, but be careful not use interfaces that are too low.
> > > Most methods that now receive an ArrayList will still compile if
> > > you
> > > change the parameter type to Collection, but make sure that you
> > > don't implicitly assume some ordering, e.g.
> > >
> > > -Allon
> > >
> > > ----- Original Message -----
> > > > From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> > > > To: "engine-devel" <engine-devel at ovirt.org>
> > > > Sent: Thursday, March 1, 2012 5:18:03 PM
> > > > Subject: [Engine-devel] Use java.util.Collection where
> > > > possible?
> > > >
> > > > Hi,
> > > > I see that in some places in engine-core we use Java.Util.List,
> > > > or
> > > > even
> > > > Java.Util.ArrayList as types of method arguments, while in the
> > > > method
> > > > code we do nothing besides iterating over the collection.
> > > > I then found all kinds of usages like this:
> > > >
> > > > x.foo(new ArrayList<MyType>(myMap.values()));
> > > >
> > > > As you can see need to instantiate a new ArrayList in order to
> > > > use
> > > > the
> > > > values of the map in method foo.
> > > > Do you see any reason why not change the argument type (at
> > > > method
> > > > signature) to Collection in such places, where possible?
> > > >
> > > > Yair
> > > >
> > > > _______________________________________________
> > > > Engine-devel mailing list
> > > > Engine-devel at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > >
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
>
More information about the Engine-devel
mailing list