You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@isis.apache.org by Robert Matthews <rm...@nakedobjects.org> on 2010/12/19 22:18:12 UTC
When should a List be preferred over a simple array? ( was Re: [jira]
Created: (ISIS-57) Remove arrays from all public APIs, replace with (immutable)
lists of elements.)
Should we replacing all arrays with lists?
1) A simple statement like
ObjectAction action = spec.getObjectAction(ObjectActionType.USER,
"userFor", new ObjectSpecification[] {userid.getSpecification()});
becomes
List<ObjectSpecification> parameters = new
ArrayList<ObjectSpecification>();
parameters.add(spec);
ObjectAction action =
userAdminService.getSpecification().getObjectAction(ObjectActionType.USER,
"userFor", parameters);
Which is not much of an improvement!
2) If that was the right thing to do then java.lang.reflect.Method would
have the following method
Object invoke(Object object, List<Object> parameters)
to replace
Object invoke(Object object, Object[] parameters)
but it doesn't. My Java in a nutshell says it has this instead
Object invoke(Object object, Object... parameters)
which is an array by another name.
3) The Java people haven't suggested removing arrays from use so they
must be good for something.
Maybe (2) is a clue as to how we should be handling these situations
where all want to do is pass in a set of somthing.
Regards
Rob
On 17/12/10 16:34, Dan Haywood (JIRA) wrote:
> Remove arrays from all public APIs, replace with (immutable) lists of elements.
> -------------------------------------------------------------------------------
>
> Key: ISIS-57
> URL: https://issues.apache.org/jira/browse/ISIS-57
> Project: Isis
> Issue Type: Improvement
> Reporter: Dan Haywood
>
>
> This is an umbrella JIRA to steadily improve our API. If you find a change you want to make, create a subtask under this one and action on it.
>
> This umbrella JIRA won't get a fix version until all APIs have been impacted, which could take some time. Individual subtasks can be assigned fix versions as they are done.
>
>
Re: When should a List be preferred over a simple array?
Posted by Mike Burton <mi...@mycosystems.co.uk>.
My only reason for using arrays would be for conciseness as per Rob's point 1) but as Dan says the List equivalent can be as good if we use Arrays.asList(), so:
+1 @ "replace arrays with lists"
Mike
On 20 Dec 2010, at 08:35, Dan Haywood wrote:
> Hi Rob,
>
>
> On 19/12/2010 21:18, Robert Matthews wrote:
>> Should we replacing all arrays with lists?
> Yes, I think so. Lots of reasons:
> - lists can be made immutable, which will reduce defects (in fact, I'd like us to get to evolve the metamodel APIs so that they are fully immutable)
> - lists correctly support covariance/contravariance, whereas arrays do not (ArrayStoreException anyone).
> - list lets us change the implementation (ArrayList vs LinkedList or some other mechanism) whereas an array exposes its "implementation"
> - lists can be decorated, eg made thread-safe (Collections.synchronized*())
> - lists are a higher level of abstraction compared to arrays
>
> There's also pragmatic reasons:
> - with google-collections there is great support for processing lists in a declarative way (eg apply a Function to transform).
> - just compare appending one list to another (list.addAll(otherList) vs the huge amount of code needed to do the same thing with arrays)
> - lists can grow in size, which simplifies the code
>
> Others think so too:
> - Josh Bloch, in Effective Java (item 25); see [1]
> - javapractices.com [2]
> - these responses on stackoverflow [3]
>
> To answer your points:
>>
>> 1) A simple statement like
>>
>> ObjectAction action = spec.getObjectAction(ObjectActionType.USER, "userFor", new ObjectSpecification[] {userid.getSpecification()});
>>
>> becomes
>>
>> List<ObjectSpecification> parameters = new ArrayList<ObjectSpecification>();
>> parameters.add(spec);
>> ObjectAction action = userAdminService.getSpecification().getObjectAction(ObjectActionType.USER, "userFor", parameters);
>>
>> Which is not much of an improvement!
>>
> or just:
> ObjectAction action = spec.getObjectAction(ObjectActionType.USER, "userFor", Arrays.asList(userid.getSpecification()));
>
> which is actually shorted than the array equivalent!
>
>
>> 2) If that was the right thing to do then java.lang.reflect.Method would have the following method
>>
>> Object invoke(Object object, List<Object> parameters)
>>
>> to replace
>>
>> Object invoke(Object object, Object[] parameters)
>>
>> but it doesn't. My Java in a nutshell says it has this instead
>>
>> Object invoke(Object object, Object... parameters)
>>
>> which is an array by another name.
>>
> Well, there are lots of APIs from Java 1.0 that aren't the best (java.util.Date, anyone?).
>
> In general the java.lang.reflect does use lots of arrays, you are right, (eg Class#getDeclaredMethods() returning Method[]), but I think that's because they wanted typesafety and generics didn't exist.
>
>
>> 3) The Java people haven't suggested removing arrays from use so they must be good for something.
>>
> Well, they've never removed anything....
>
> It's fine as an underlying data structure (after all, ArrayList is backed by an array), but it isn't appropriate for API.
>
>
>> Maybe (2) is a clue as to how we should be handling these situations where all want to do is pass in a set of somthing.
>>
>> Regards
>> Rob
>>
>
> I think the original reason you probably because of their typesafety (covariance issues aside). However, generics mean that isn't a factor anymore.
>
> In general, I want the API for Isis to evolve and keep pace with recognized best practice, eg being immutable wherever possible. I truly think that doing this will help us build community; so that a casual would-be user will browse our API and "grok" it immediately. This is just one step along that journey.
>
> I'd be interested in other opinions here; we have lots of experienced Java guys here. Mark, Sigi, Nour, Kevin, Dave, Alexander, Mike, Sabine, Vango, anyone else listening in ... what say you all?
>
> Cheers
> Dan
>
> [1] http://books.google.co.uk/books?id=ka2VUBqHiWkC&pg=PA119&lpg=PA119&dq=java+prefer+lists+over+arrays&source=bl&ots=yXLhQhqZRZ&sig=bCY4OyUfzvgE17-l2HEHbi5cGyA&hl=en&ei=HBEPTfCtDJO6hAf274i3Dg&sa=X&oi=book_result&ct=result&resnum=7&sqi=2&ved=0CEYQ6AEwBg#v=onepage&q&f=false
> [2] http://www.javapractices.com/topic/TopicAction.do?Id=39
> [3] http://stackoverflow.com/questions/2391553/why-is-it-preferred-to-use-lists-instead-of-arrays-in-java
> [4] http://stackoverflow.com/questions/1589813/when-to-use-a-list-over-an-array-in-java
>
Re: When should a List be preferred over a simple array?
Posted by Robert Matthews <rm...@nakedobjects.org>.
> So to summarize:
> - where we currently have a method that receives an array representing
> parameters, this should be replaced at least by a varargs
Especially when you are providing a set of parameters to run a method
(this is the case when I want to pass in 3 values, for example, rather
than just one. And those set of parameters is only used in calling the
method; if the set is typically also used for other things then it
suggests a list.
> and possibly overloaded to also accept a List
Nice addition.
> - where we currently have a method that receives either an array
> representing some other structure
I'm not sure what you mean by "some other structure"?
> , or receives more than one array, then it should be replaced with a List
By this, you mean if you can't have two varargs? Again, I think it the
first point would apply to the current set that is used for multiple
parameter when actually writing the method call. The examples I can
think of are for helper methods where a set of arrays are constructed
before the method call. What I'd like to ensure is that in cases where
you are calling a method directly that you can list everything in the
method call without resorting to creating arrays or building lists, and
the vararg does that elegantly.
> - where we have a method returning an array, this should be replaced
> by a list (preferably immutable, but the Javadoc should indicate)
>
Definitely
Rob
Re: When should a List be preferred over a simple array?
Posted by Dan Haywood <dk...@gmail.com>.
On 20/12/2010 10:21, Robert Matthews wrote:
> At the moment I can't think of any reasons not to get rid of the array
> parameters, but the replacements should be a var-arg or a List. In
> particular var-arg should be used when you would have had a reference
> parameter if there was only one instance, eg if all methods invoked
> reflectively only had one parameter.
>
Fine with this.
So to summarize:
- where we currently have a method that receives an array representing
parameters, this should be replaced at least by a varargs, and possibly
overloaded to also accept a List
- where we currently have a method that receives either an array
representing some other structure, or receives more than one array, then
it should be replaced with a List
- where we have a method returning an array, this should be replaced by
a list (preferably immutable, but the Javadoc should indicate)
Thx
Dan
> Regards
> Rob
>
Re: When should a List be preferred over a simple array?
Posted by Robert Matthews <rm...@nakedobjects.org>.
Dan
I'm happy with generic lists except in one case, where I am simply
passing in a list of parameters. Here there no reason for the extra
work the programmer has to do and the code reader subsequently has to
read. In these cases - and it applies particularly to requests made to
the meta model to do something.
At the moment I can't think of any reasons not to get rid of the array
parameters, but the replacements should be a var-arg or a List. In
particular var-arg should be used when you would have had a reference
parameter if there was only one instance, eg if all methods invoked
reflectively only had one parameter.
Regards
Rob
On 20/12/10 08:35, Dan Haywood wrote:
> Hi Rob,
>
>
> On 19/12/2010 21:18, Robert Matthews wrote:
>> Should we replacing all arrays with lists?
> Yes, I think so. Lots of reasons:
> - lists can be made immutable, which will reduce defects (in fact, I'd
> like us to get to evolve the metamodel APIs so that they are fully
> immutable)
> - lists correctly support covariance/contravariance, whereas arrays do
> not (ArrayStoreException anyone).
> - list lets us change the implementation (ArrayList vs LinkedList or
> some other mechanism) whereas an array exposes its "implementation"
> - lists can be decorated, eg made thread-safe
> (Collections.synchronized*())
> - lists are a higher level of abstraction compared to arrays
>
> There's also pragmatic reasons:
> - with google-collections there is great support for processing lists
> in a declarative way (eg apply a Function to transform).
> - just compare appending one list to another (list.addAll(otherList)
> vs the huge amount of code needed to do the same thing with arrays)
> - lists can grow in size, which simplifies the code
>
> Others think so too:
> - Josh Bloch, in Effective Java (item 25); see [1]
> - javapractices.com [2]
> - these responses on stackoverflow [3]
>
> To answer your points:
>>
>> 1) A simple statement like
>>
>> ObjectAction action = spec.getObjectAction(ObjectActionType.USER,
>> "userFor", new ObjectSpecification[] {userid.getSpecification()});
>>
>> becomes
>>
>> List<ObjectSpecification> parameters = new
>> ArrayList<ObjectSpecification>();
>> parameters.add(spec);
>> ObjectAction action =
>> userAdminService.getSpecification().getObjectAction(ObjectActionType.USER,
>> "userFor", parameters);
>>
>> Which is not much of an improvement!
>>
> or just:
> ObjectAction action = spec.getObjectAction(ObjectActionType.USER,
> "userFor", Arrays.asList(userid.getSpecification()));
>
> which is actually shorted than the array equivalent!
>
>
>> 2) If that was the right thing to do then java.lang.reflect.Method
>> would have the following method
>>
>> Object invoke(Object object, List<Object> parameters)
>>
>> to replace
>>
>> Object invoke(Object object, Object[] parameters)
>>
>> but it doesn't. My Java in a nutshell says it has this instead
>>
>> Object invoke(Object object, Object... parameters)
>>
>> which is an array by another name.
>>
> Well, there are lots of APIs from Java 1.0 that aren't the best
> (java.util.Date, anyone?).
>
> In general the java.lang.reflect does use lots of arrays, you are
> right, (eg Class#getDeclaredMethods() returning Method[]), but I think
> that's because they wanted typesafety and generics didn't exist.
>
>
>> 3) The Java people haven't suggested removing arrays from use so they
>> must be good for something.
>>
> Well, they've never removed anything....
>
> It's fine as an underlying data structure (after all, ArrayList is
> backed by an array), but it isn't appropriate for API.
>
>
>> Maybe (2) is a clue as to how we should be handling these situations
>> where all want to do is pass in a set of somthing.
>>
>> Regards
>> Rob
>>
>
> I think the original reason you probably because of their typesafety
> (covariance issues aside). However, generics mean that isn't a factor
> anymore.
>
> In general, I want the API for Isis to evolve and keep pace with
> recognized best practice, eg being immutable wherever possible. I
> truly think that doing this will help us build community; so that a
> casual would-be user will browse our API and "grok" it immediately.
> This is just one step along that journey.
>
> I'd be interested in other opinions here; we have lots of experienced
> Java guys here. Mark, Sigi, Nour, Kevin, Dave, Alexander, Mike,
> Sabine, Vango, anyone else listening in ... what say you all?
>
> Cheers
> Dan
>
> [1]
> http://books.google.co.uk/books?id=ka2VUBqHiWkC&pg=PA119&lpg=PA119&dq=java+prefer+lists+over+arrays&source=bl&ots=yXLhQhqZRZ&sig=bCY4OyUfzvgE17-l2HEHbi5cGyA&hl=en&ei=HBEPTfCtDJO6hAf274i3Dg&sa=X&oi=book_result&ct=result&resnum=7&sqi=2&ved=0CEYQ6AEwBg#v=onepage&q&f=false
>
> [2] http://www.javapractices.com/topic/TopicAction.do?Id=39
> [3]
> http://stackoverflow.com/questions/2391553/why-is-it-preferred-to-use-lists-instead-of-arrays-in-java
>
> [4]
> http://stackoverflow.com/questions/1589813/when-to-use-a-list-over-an-array-in-java
>
>
Re: When should a List be preferred over a simple array?
Posted by Dan Haywood <dk...@gmail.com>.
Hi Rob,
On 19/12/2010 21:18, Robert Matthews wrote:
> Should we replacing all arrays with lists?
Yes, I think so. Lots of reasons:
- lists can be made immutable, which will reduce defects (in fact, I'd
like us to get to evolve the metamodel APIs so that they are fully
immutable)
- lists correctly support covariance/contravariance, whereas arrays do
not (ArrayStoreException anyone).
- list lets us change the implementation (ArrayList vs LinkedList or
some other mechanism) whereas an array exposes its "implementation"
- lists can be decorated, eg made thread-safe (Collections.synchronized*())
- lists are a higher level of abstraction compared to arrays
There's also pragmatic reasons:
- with google-collections there is great support for processing lists in
a declarative way (eg apply a Function to transform).
- just compare appending one list to another (list.addAll(otherList) vs
the huge amount of code needed to do the same thing with arrays)
- lists can grow in size, which simplifies the code
Others think so too:
- Josh Bloch, in Effective Java (item 25); see [1]
- javapractices.com [2]
- these responses on stackoverflow [3]
To answer your points:
>
> 1) A simple statement like
>
> ObjectAction action = spec.getObjectAction(ObjectActionType.USER,
> "userFor", new ObjectSpecification[] {userid.getSpecification()});
>
> becomes
>
> List<ObjectSpecification> parameters = new
> ArrayList<ObjectSpecification>();
> parameters.add(spec);
> ObjectAction action =
> userAdminService.getSpecification().getObjectAction(ObjectActionType.USER,
> "userFor", parameters);
>
> Which is not much of an improvement!
>
or just:
ObjectAction action = spec.getObjectAction(ObjectActionType.USER,
"userFor", Arrays.asList(userid.getSpecification()));
which is actually shorted than the array equivalent!
> 2) If that was the right thing to do then java.lang.reflect.Method
> would have the following method
>
> Object invoke(Object object, List<Object> parameters)
>
> to replace
>
> Object invoke(Object object, Object[] parameters)
>
> but it doesn't. My Java in a nutshell says it has this instead
>
> Object invoke(Object object, Object... parameters)
>
> which is an array by another name.
>
Well, there are lots of APIs from Java 1.0 that aren't the best
(java.util.Date, anyone?).
In general the java.lang.reflect does use lots of arrays, you are right,
(eg Class#getDeclaredMethods() returning Method[]), but I think that's
because they wanted typesafety and generics didn't exist.
> 3) The Java people haven't suggested removing arrays from use so they
> must be good for something.
>
Well, they've never removed anything....
It's fine as an underlying data structure (after all, ArrayList is
backed by an array), but it isn't appropriate for API.
> Maybe (2) is a clue as to how we should be handling these situations
> where all want to do is pass in a set of somthing.
>
> Regards
> Rob
>
I think the original reason you probably because of their typesafety
(covariance issues aside). However, generics mean that isn't a factor
anymore.
In general, I want the API for Isis to evolve and keep pace with
recognized best practice, eg being immutable wherever possible. I truly
think that doing this will help us build community; so that a casual
would-be user will browse our API and "grok" it immediately. This is
just one step along that journey.
I'd be interested in other opinions here; we have lots of experienced
Java guys here. Mark, Sigi, Nour, Kevin, Dave, Alexander, Mike, Sabine,
Vango, anyone else listening in ... what say you all?
Cheers
Dan
[1]
http://books.google.co.uk/books?id=ka2VUBqHiWkC&pg=PA119&lpg=PA119&dq=java+prefer+lists+over+arrays&source=bl&ots=yXLhQhqZRZ&sig=bCY4OyUfzvgE17-l2HEHbi5cGyA&hl=en&ei=HBEPTfCtDJO6hAf274i3Dg&sa=X&oi=book_result&ct=result&resnum=7&sqi=2&ved=0CEYQ6AEwBg#v=onepage&q&f=false
[2] http://www.javapractices.com/topic/TopicAction.do?Id=39
[3]
http://stackoverflow.com/questions/2391553/why-is-it-preferred-to-use-lists-instead-of-arrays-in-java
[4]
http://stackoverflow.com/questions/1589813/when-to-use-a-list-over-an-array-in-java