-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

Dimitri Maziuk schreef:

No, it becomes Foo.

If it causes a compiler error, then it can have nothing to do with RTTE
(took me a while to guess this is run-time type erasure), as the first
two letters imply.

Or something.

Indeed.  Do read up on generics.

That?s the other way.  But you take you arse with you, as this nice
Russian proverb says.

H.

   No, what he means is you can't do this:

class Foo<ArrayList> {
 public ArrayList getMyThing() {...}
}

I.e. you can't specify an "actual class" (where ArrayList is an example of
an actual class), because if you knew ahead of time what actual class you
wanted, you could just put it directly into the code (as seen here in
"public ArrayList getMyThing()". Generics are for when you DON'T know the
type, as in:

class Foo<T> {
 public T getMyThing() {...}
}

   Chris was subtly saying that the code you provided doesn't mean what you
think it means. You've declared a new generic type variable called
"Iterable", when you probably mean to refer to the existing Iterable. It's
similar to this mistake:

class Foo {
 int x;

 public void someMethod() {
   int x; //shadowing is occuring here.
 }
}

   Instead of referring to the existing field called "x", you've created a
new local variable called "x".

   Also, for claritiy, here's the code Chris was referring to as being
"bad" and in which shadowing is occuring (which seems to have gotten
snipped)

<quote>
interface Foo<Iterable> {
 <T> void setBar( Iterable T );
}
</quote>

The question is, what is it that's generic? Is it what specific subclass of
Iterable that's in use that is generic? If so, then the code should be

interface Foo<T extends Iterable<?>> {
 void setBar(T t);
}

Or is it the type of Iterable which is generic? If so, then the code should
be as Chris posted above. Generics are not used only for collections, which
is why it doesn't make sense to restriction the conceptual definition of
generics as "the type of elements contained in a collection".

   Well, no, it's not valid. You need to specify a return type for the
setBar() method. But let's pretend you specified that it returns T, for
example.

   It does something different from the rest of the code posted in this
thread. It's like saying the "Hello World!" program is just as much "valid
Java" as the "Azureus" program. Yes, they both consist of Java code, but
they do two different things.

   - Oliver

I think you've run into a problem with Sun's not particularly general
description of the purpose of generics.  Generics are used by the
collections API to allow you to communicate the type of a collection.  
Since most people come across generics in the context of the collections
API, it makes some sense for Sun to say that (depending on context,
which I didn't see)... but it's an incomplete statement.

In your case, you already know the basic type of the collection (it's
ColHdr), so what you need to communicate is the type parameter to
ColHdr.  The way you do that is with a type parameter to Table, as such:

   public interface Table<C>
   {
       public void doSomethingWith(ColHdr<C> header);
   }

No, I mean you can't do this:

   class Foo<ArrayList<Comparable<T>>> ...

That doesn't work, because the Java language requires that the formal
type parameter list following a class declaration consists of actual
type parameters.  You seem to want to declare type parameters in context
and have the compiler match that against type names in a kind of pattern
matching, and you just can't do it that way.

Your code above, though, with some additions, does make sense:

   class Foo<T extends ArrayList<Comparable<T>>>
   {
       public void doSomethingWith(T t) { ... }
       public T getSomething() { ... }
   }

This says that there's a type called T, and that T is constrained to be,
or to be is a subclass of, ArrayList<Comparable<T>>.  Subclasses of
ArrayList are rather rare, but nevertheless you can do this.  Its
advantage (though a little dubious) over just writing a non-generic Foo
using ArrayList is that if someone wants to create a Foo that only works
with instances of the subclass javax.management.AttributeList (which
subclasses ArrayList), they can do so, and they can be assured that the
compiler will complain if they pass anything else, and that they don't
need an explicit cast on the result of getSomething().

Note that this only makes sense if you expect someone to use Foo in such
a way that it's important that it only works with some subclass of
ArrayList.  Otherwise, you wouldn't write a generic class.  (Also, you
probably want a wildcard in the type parameter to Comparable, but that's
a different matter.)

Yep, because you haven't declared T.

That is, in fact, not just faking it, but rather doing what you might
have meant to begin with.

You mean that you could do:

   interface Table<C, T extends ColHdr<C>> { ... }

Yes, you can, but I don't think you want to.  Do you expect people to
subclass ColHdr?  If they do, is it important when they use a table that
they remember exactly which subclass of ColHdr they chose?  If the
answer to both of these questions is yes, then the above is what you
want.  Otherwise, you really want this simpler code:

   interface Table<C> { ... use ColHdr<C> here ... }

Why would I see the C++ typename keyword?  These are generics in Java.  
They have very little to do with templates in C++, aside from solving
some of the same problems and using a similar syntax.  The core concepts
are very different.  For example, there is no such thing as type bounds
or erasures in C++.

Watch the quoting.  My comment referred to this code:

   interface Foo<Iterable> { ... }

No, in the code above, it's the name of a formal type parameter.  It has
nothing at all to do with java.lang.Iterable.  That was why I said the
code is very poor.  But yes, I understand that you wanted it to be
java.lang.Iterable.  I'm trying to explain that you are miunderstanding
the purpose of generics when you want that.  One more example:

Then do it this way:

class Foo
{
   public void add(Iterable t) { ... }
   public Iterable get(int i) { ... }
   ...
}

If you want your class to contain only Iterable elements, then you don't
need generics.  If you'd like to implement an existing generic
interface, though, then you can do so like this:

class Foo implements Collection<Iterable> { ... }

I presume you mean: class Foo<T extends Iterable> { ... }

The syntax suggests that for a good reason.  Declaring a class like that
suggests that someone does indeed want to extend the type Iterable, and
that they want to use Foo while remaining aware of the specific subtype
with respect to which this Foo instance if used.  Otherwise, you'd write
the non-generic Foo implementation I provided above.

Java does not implement C++ template specialization.  It is not a
compatible concept with Java generics.  Again, generics and C++
templates are conceptually different things, so ideas don't move over
wholesale from one to the other.

The unknown type is T.  Therefore, you specify T as the type parameter.  
You've definitely gotten too hung up on an incomplete statement in some
tutorial on generics.

Of course you can.  If you don't like the syntax, that's your problem,
and it's aesthetic/psychological rather than technical in nature.

Except it means something different.  Your form allows:

   Iterable<String> a = ...;
   Iterable<Number> b = ...;

   Foo f = new Foo();
   f.setBar(a);
   f.setBar(b);

The generic Foo above would look like this:

   Iterable<String> a = ...;
   Iterable<Number> b = ...;

   Foo<String> f = new Foo<String>();
   f.setBar(a); // OK
   f.setBar(b); // ERROR

As a side note, you may want to have written this instead:

interface Foo<T>
{
   void setBar(Iterable<? extends T> t);
}

My original code was copying yours closely to make the point, but it's
really better to use the wildcard in that situation.

I don't recall what Bruce Eckel said.  He may have said that the problem
generics solve is not serious, and I may agree with him in some
contexts.  But I'd bet a kidney that he didn't say what you're saying in
this thread.