Generics the way of the future?

X

Xu

Hi i like to know what you think about/experiences of using generics in
java.
Does it really make life easier? What are the advantages of using
generics and where should I avoid using it (if that is true)?
What are the disadvantages of using generics ?


I'm now reading this tutorial from sun:
http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf

If you have any nice links, i would like to know,

~Xu
 
P

Peter MacMillan

Xu said:
Hi i like to know what you think about/experiences of using generics in
java.
Does it really make life easier? What are the advantages of using
generics and where should I avoid using it (if that is true)?
What are the disadvantages of using generics ?


~Xu

I think the biggest win for generics are type-safe collections. I mean,
most of the time you're putting the same kind of object into a
collection and now you don't have to cast when working with them.

eg.
//---
Vector<MyClass> myClassVector;
myClassVector.add(new MyClass());
MyClass value = myClassVector.get(0);
//---

One downside is the lack of a typedef construct. I've run into (and
redesigned it to work around) situations where you get generics in
generics and it becomes a big long mess (java doesn't seem to hit a
problem with >> like C++ does).

eg.
//---
SomeGeneric<SomeInnerGeneric<SomeType>, SomeOtherGeneric<SomeOtherType>>
//---

But you can alias generics by extending the specific class:

//---
class MyClassVector extends Vector<MyClass> {}
//---

and then you could refer to Vector<MyClass> with MyClassVector instead
(obviously this is a simple example).


I <3 generics. :)
 
J

John C. Bollinger

Xu said:
Hi i like to know what you think about/experiences of using generics in
java.
Does it really make life easier? What are the advantages of using
generics and where should I avoid using it (if that is true)?

Using generic classes is great. Advantages of using generic classes: no
casting, automatic type safety, built-in documentation on how particular
instances of generic classes are intended to be used (i.e. this List is
a List of _Strings_), detection of certain problems relating to
polymorphic behavior. Writing generic classes can be a bit of a pain,
however, at least if you care to really do it right.

I don't see any place or reason to explicitly avoid using existing
generic classes.
What are the disadvantages of using generics ?

The declaration syntax is ugly and verbose, especially for complex type
parameters.
 
T

Thomas G. Marshall

John C. Bollinger coughed up:
Using generic classes is great. Advantages of using generic classes:
no casting, automatic type safety, built-in documentation on how
particular instances of generic classes are intended to be used (i.e.
this List is a List of _Strings_), detection of certain problems
relating to polymorphic behavior. Writing generic classes can be a
bit of a pain, however, at least if you care to really do it right.

I don't see any place or reason to explicitly avoid using existing
generic classes.


The declaration syntax is ugly and verbose,

/Terse/, not verbose. And I would have liked an "of" construct much better,
as someone else lurking elsewhere in comp.lang.java.mumble once suggested:

ArrayList <of String> words = new ArrayList <of String>();

or since we're likely to group right-to-left anyway:

ArrayList of String words = new ArrayList of String();
and
ArrayList of ArrayList of String words =
new ArrayList of ArrayList of String();




....[rip]...


--
Unix users who vehemently argue that the "ln" command has its arguments
reversed do not understand much about the design of the utilities. "ln
arg1 arg2" sets the arguments in the same order as "mv arg1 arg2".
Existing file argument to non-existing argument. And in fact, mv
itself is implemented as a link followed by an unlink.
 
T

Tor Iver Wilhelmsen

Thomas G. Marshall said:
ArrayList of ArrayList of String words =
new ArrayList of ArrayList of String();

But how would that syntax look wehen used for declarations and
multiple types? Like the following cases?

class MyClass<T extends Number & Serializable> {

}

Map<String, ArrayList<String>> map = ...

public void merge(Collection<? super T> c) { ...

The problem is that "of" is not a keyword, and is too likely to break
existing code if it was made one.
 
T

tzvika.barenholz

I like the effect that generics have as they are used in the new
Callable interface.
i.e. that basically a thread can return a result and that result is
generic.
like this sample code:

//run the server
ExecutorCompletionService<Socket> ecs = new
ExecutorCompletionService<Socket>(new ScheduledThreadPoolExecutor(7));
Future<Socket> future = ecs.submit(new Callable<Socket>(){
public Socket call() throws Exception {
Socket socket = server.accept();
return socket;
}});

in this case the parameterized type is a Socket.
In the past code such as this would have to return Object. Yuck.
 
J

John C. Bollinger

Thomas said:
John C. Bollinger coughed up:

/Terse/, not verbose.

You snipped the part where I qualified that as applying mostly to
complex type parameters. Have you ever needed to use a type parameter
that was itself a generic type? With bounded wildcards in its type
parameter(s)? It gets very lengthy and very ugly very quickly. That's
what I was talking about.
 
R

Ross Bamford

You snipped the part where I qualified that as applying mostly to
complex type parameters. Have you ever needed to use a type parameter
that was itself a generic type? With bounded wildcards in its type
parameter(s)? It gets very lengthy and very ugly very quickly. That's
what I was talking about.
I would agree with both - the syntax itself is terse, but Generic
declarations can become quite verbose. (Diplomacy degree, $9.99 well
spent :))

Generics are *great*. I first used them early on my current project,
where I had a blank canvas, and now the project has grown and evolved I
cannot understate the value of knowing that whatever else goes wrong,
I'm passing the right *type* of object...

Plus, maybe it's chance but usually by this point I'd be coming across
little problems I didn't know about and are hard to trace (one String in
a Vector of Integers, anyone?), but with this one things seem to slot in
and work like a dream :)

Anyone new to Java should make sure they learn up on Generics and make
use of them at [almost] every possible juncture :)

Cheers,
Ross
 
T

Thomas G. Marshall

Tor Iver Wilhelmsen coughed up:
"Thomas G. Marshall"


But how would that syntax look wehen used for declarations and
multiple types? Like the following cases?

class MyClass<T extends Number & Serializable> {

}

Map<String, ArrayList<String>> map = ...

public void merge(Collection<? super T> c) { ...


Funny, I was just thinking of this while out walking the dog today.

This is of course all just silly musing, so punt it if you like and do
something more productive like downloading lesbian porn.


-----Option 1------

Using "/": Simple single-types added for comparison:

ArrayList of String: "arraylist of strings"

ArrayList of ArrayList of String: "arraylist of arraylists of strings"

ArrayList of HashMap of String/Collection: "arraylist of hashmaps, each
one a hashmap of key:String and value:Collection

HashMap of String/(ArrayList of Long): hashmap of key:String and
value:an arraylist of Longs

OR maybe "+":

ArrayList of HashMap of String+Collection: "arraylist of hashmaps, each
one a hasshmap of key:String and value:Collection

HashMap of String+(ArrayList of Long): hashmap of key:String and
value:an arraylist of Longs

-----Option 2------
You put in things like an "and" clause, but what I'd really prefer is
something a little more like a named parameter:

Map of Key:String and Value:ArrayList of String map = ...

Or if you really got worried about the grouping, the good ol' parens fix it
all:

Map of Key:String and Value:(ArrayList of String) map = ...

Note that this would mean that something like "Type" would be the default
type and could be removed, so the

ArrayList of String

is the shorthand for

ArrayList of Type:String

So the map thing might also be:

Map of Key:String and Value:(ArrayList of Type:String) map = ...

The "Type" is just a default named parameter.


I prefer option 1 overall. I think it's much cleaner than what we have, but
YMMV....

The problem is that "of" is not a keyword, and is too likely to break
existing code if it was made one.

Oh there's always /that/. :)
 
R

Ross Bamford

Tor Iver Wilhelmsen coughed up:


Funny, I was just thinking of this while out walking the dog today.

This is of course all just silly musing, so punt it if you like and do
something more productive like downloading lesbian porn.


-----Option 1------

Using "/": Simple single-types added for comparison:

ArrayList of String: "arraylist of strings"

ArrayList of ArrayList of String: "arraylist of arraylists of strings"

ArrayList of HashMap of String/Collection: "arraylist of hashmaps, each
one a hashmap of key:String and value:Collection

HashMap of String/(ArrayList of Long): hashmap of key:String and
value:an arraylist of Longs

OR maybe "+":

ArrayList of HashMap of String+Collection: "arraylist of hashmaps, each
one a hasshmap of key:String and value:Collection

HashMap of String+(ArrayList of Long): hashmap of key:String and
value:an arraylist of Longs

-----Option 2------
You put in things like an "and" clause, but what I'd really prefer is
something a little more like a named parameter:

Map of Key:String and Value:ArrayList of String map = ...

Or if you really got worried about the grouping, the good ol' parens fix it
all:

Map of Key:String and Value:(ArrayList of String) map = ...

Note that this would mean that something like "Type" would be the default
type and could be removed, so the

ArrayList of String

is the shorthand for

ArrayList of Type:String

So the map thing might also be:

Map of Key:String and Value:(ArrayList of Type:String) map = ...

The "Type" is just a default named parameter.


I prefer option 1 overall. I think it's much cleaner than what we have, but
YMMV....

Yes but is it Java?

The current system is pretty good, it just takes some getting used to.
It's like everything else, once you get the hang of it it becomes
automatic. Plus, it's easy to see a genericised (?) type at a glance.

Also it would make parsing more difficult, syntax errors harder to
trace, and the whole lexical parse stage more error prone, since
optional bareword tokens would be involved, whereas a generic type is
still one language token.

Oh there's always /that/. :)

:)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,769
Messages
2,569,580
Members
45,055
Latest member
SlimSparkKetoACVReview

Latest Threads

Top