Generics, for non collection types

J

J. Davidson

Andreas said:
Also, I doubt that a parameterless operation is necessarily
a constant ...
Since such an operation may still depend on the pre-state and
leave a different post-state, constant may not be an adequate
term.

Certainly not.

In my experience there are at least two common cases of parameter-less
methods whose return values vary over time.

Getters, when there's a setter for whatever they get, or it otherwise is
changeable.

And "next" methods, like InputStream.read(), Random.nextInt(),
Iterator.next(), and the like, and anything else they affect, like
Iterator.hasNext() and FileChannel.position().

Now, a parameter-less method on an //immutable// object might be much
more likely to have a constant return value.

- jenny
 
T

Tom Anderson

Certainly not.

In my experience there are at least two common cases of parameter-less
methods whose return values vary over time.

Getters, when there's a setter for whatever they get, or it otherwise is
changeable.

And "next" methods, like InputStream.read(), Random.nextInt(),
Iterator.next(), and the like, and anything else they affect, like
Iterator.hasNext() and FileChannel.position().

Now, a parameter-less method on an //immutable// object might be much more
likely to have a constant return value.

Ah, but here we're talking about monads. Monads are something a bit
special, and come from the crazy mixed-up world of functional programming.
There, things like setters and next() do not exist. I haven't read
Stefan's java, or his german, so i can't be sure that this applies to the
operations we're talking about translation into java, but a no-arg
function in a functional language *is* a constant. Although possibly *not*
when monads are involved, since that's kind of the point of monads.

So basically i have no idea.

But i do know that some people, when confronted with a problem, think "I
know, I'll use monads." Now they have S(1) problems.

tom
 
L

lscharen

Hi,

What is the interest of generic types outside
the field of collection types ?

All the examples I found are based
on collection types (thanks to generics
, we avoid an explicit cast when we get an element
from a collection ... ok, that's fine.

But are there any other interesting uses of
generic types ?

I happen to think the way generics are used in the Emum<E extends
Enum<E>> is quite interesting. I've used that idiom myself in several
data structures where I want to swap out some internal class.

For instance, a generic Tree data structure should have the notion of
Nodes, but we want the freedom to implement those Node classes in
different, efficient ways depending on the Tree type. Heaps are tree,
but can be efficiently implement on top of an array. A Red-Black Tree
needs Nodes with an extra "red" boolean flag, etc....

One can implement a generic data type like this:

public interface Tree<V, N extends Node<V, N>> {}
public interface Node<T, Q extends Node<T, Q>> {}
public interface BinaryTree<K extends Comparable<K>, V, N extends
BinaryTreeNode<K,V,N>> extends Tree<E, N>
public interface BinaryTreeNode<S extends Comparable<S>, T, Q extends
BinaryTreeNode<S, T, Q>> extends Node<T, Q>

Now, a concrete implementation of a Red-Black Tree class might look
like this

class RBTree extends BinaryTree<Integer, String, RBNode> {}
class RBNode extends BinaryTreeNode<Integer, String, RBNode> {}

All the complicated-looking generic declarations just make sure that
when I glue a TreeNode class onto a Tree class the Key and Value types
all match up. This lets me have a very loose coupling of the Tree and
Node classes, but still enforce type-safety.

-Lucas

The construct Foo<T extends Foo<T>> allows the class to use T as a
kind of self-referential type, e.g. Tree and
 
Joined
Nov 25, 2008
Messages
17
Reaction score
0
ArrayList<Person> this is the new function of jdk_1.5.
so use this mode,it's simple to stor,read.
use more time,you'll find it good for us to develop
 
J

Joshua Cranmer

I happen to think the way generics are used in the Emum<E extends
Enum<E>> is quite interesting. I've used that idiom myself in several
data structures where I want to swap out some internal class.

(Sudden realization) Oh, that's where the infinite generic types comes in.
For instance, a generic Tree data structure should have the notion of
Nodes, but we want the freedom to implement those Node classes in
different, efficient ways depending on the Tree type. Heaps are tree,
but can be efficiently implement on top of an array. A Red-Black Tree
needs Nodes with an extra "red" boolean flag, etc....

I'm not sure how useful a setup would be, since most tree-based
structures don't all need the same access points. A heap implementation
isn't going to care much about postorder tree traversal after all.

Besides, this usage would qualify as "collection types," if you want to
be pedantic.
 
L

Lew

Arne said:
JSR777 - Standard for key mappings in Java IDE's

Is that a real JSR? How in the bloody blazes can Java define the keystrokes
for applications? That's not part of the language.

What a stupid idea.
 
L

lscharen

I'm not sure how useful a setup would be, since most tree-based
structures don't all need the same access points. A heap implementation
isn't going to care much about postorder tree traversal after all.

Yes, but it's nice to have the consistency to write code like this

BinaryTree<E> tree = new BinaryHeap<E>();

and then go about one's business. And besides, someone might want to
extend the BinaryHeap class in such a way that the postorder traversal
is now meaningful...
Besides, this usage would qualify as "collection types," if you want to
be pedantic.

Sure, but the real point of my example was to show how generics can be
used to combine the implementation classes of two coupled interfaces
in a type-safe manner.

-Lucas
 
T

Tom Anderson

Is that a real JSR? How in the bloody blazes can Java define the keystrokes
for applications? That's not part of the language.

What a stupid idea.

Yeah. I've been arguing on the mailing list for weeks to have
alt-shift-leftarrow-downarrow-rightarrow-P be the standard key combo for
HADOKEN!!!, but the idiot committee just aren't listening.

tom
 
D

Daniel Pitts

jean said:
Hi,

What is the interest of generic types outside
the field of collection types ?

All the examples I found are based
on collection types (thanks to generics
, we avoid an explicit cast when we get an element
from a collection ... ok, that's fine.

But are there any other interesting uses of
generic types ?

thanks !

jean
Look at the Callable interface for a useful example that isn't a collection.

I also use it in a generic Factory<T> interface that I've created, as
well as in many "generic" classes that need to know only the parent type
of a particular object reference, but may be extended for more specific
types.
 

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,778
Messages
2,569,605
Members
45,238
Latest member
Top CryptoPodcasts

Latest Threads

Top