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" <[email protected]> > To: "Danny Rankevich" <[email protected]> > Cc: "engine-devel" <[email protected]>, "Yair Zaslavsky" > <[email protected]> > 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" <[email protected]> > > To: "Yair Zaslavsky" <[email protected]> > > Cc: "engine-devel" <[email protected]> > > 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" <[email protected]> > > > To: "Yair Zaslavsky" <[email protected]> > > > Cc: "engine-devel" <[email protected]> > > > 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" <[email protected]> > > > > To: "engine-devel" <[email protected]> > > > > 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 > > > > [email protected] > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > _______________________________________________ > > > Engine-devel mailing list > > > [email protected] > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > _______________________________________________ > > Engine-devel mailing list > > [email protected] > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
