8:52 p.m.
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(a)redhat.com>
To: "Danny Rankevich" <danny.ran(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Yair Zaslavsky"
<yzaslavs(a)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(a)redhat.com>
> To: "Yair Zaslavsky" <yzaslavs(a)redhat.com>
> Cc: "engine-devel" <engine-devel(a)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(a)redhat.com>
> > To: "Yair Zaslavsky" <yzaslavs(a)redhat.com>
> > Cc: "engine-devel" <engine-devel(a)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(a)redhat.com>
> > > To: "engine-devel" <engine-devel(a)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(a)ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>