[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
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@redhat.com> To: "engine-devel" <engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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@redhat.com> To: "Yair Zaslavsky" <yzaslavs@redhat.com> Cc: "engine-devel" <engine-devel@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@redhat.com> To: "engine-devel" <engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Danny are you sure? IIRC GWT RPC Oracle wont be able to pick the right implementatione and will generate code for any possible concrete impl, Asaf. ----- Original Message -----
From: "Danny Rankevich" <danny.ran@redhat.com> To: "Yair Zaslavsky" <yzaslavs@redhat.com> Cc: "engine-devel" <engine-devel@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@redhat.com> To: "Yair Zaslavsky" <yzaslavs@redhat.com> Cc: "engine-devel" <engine-devel@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@redhat.com> To: "engine-devel" <engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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@redhat.com> To: "Danny Rankevich" <danny.ran@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Yair Zaslavsky" <yzaslavs@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@redhat.com> To: "Yair Zaslavsky" <yzaslavs@redhat.com> Cc: "engine-devel" <engine-devel@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@redhat.com> To: "Yair Zaslavsky" <yzaslavs@redhat.com> Cc: "engine-devel" <engine-devel@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@redhat.com> To: "engine-devel" <engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
From: "Danny Rankevich" <danny.ran@redhat.com> To: "Asaf Shakarchi" <ashakarc@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org> Sent: Thursday, March 15, 2012 7:52:47 PM Subject: Re: [Engine-devel] Use java.util.Collection where possible?
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... Yes it works, but again, IIRC gwt compiler, while generating js has to take into account all possible variants of the Collection in the compilation unit, including all the classes impl Collection and Serializable interface in the class path. So that will cause the permutations to be much larger, it also affects compile time and the app size.
----- Original Message -----
From: "Asaf Shakarchi" <ashakarc@redhat.com> To: "Danny Rankevich" <danny.ran@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Yair Zaslavsky" <yzaslavs@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@redhat.com> To: "Yair Zaslavsky" <yzaslavs@redhat.com> Cc: "engine-devel" <engine-devel@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@redhat.com> To: "Yair Zaslavsky" <yzaslavs@redhat.com> Cc: "engine-devel" <engine-devel@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@redhat.com> To: "engine-devel" <engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
participants (4)
-
Allon Mureinik -
Asaf Shakarchi -
Danny Rankevich -
Yair Zaslavsky