Weblogs Forum - Use cases for Generics

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
Use cases for Generics

39 replies on 3 pages. Most recent reply: Jan 12, 2006 10:59 AM by Mo Welch

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 39 replies on 3 pages [ « | 1 2 3 ]

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Use cases for Generics

Posted: Nov 10, 2005 7:24 AM

> @James
>
> > All I am saying is that generics are not needed to
> return
> > more specific types from methods. There are lots of
> other
> > uses for generics, this just isn't a poweful use of
> them.
>
> But Bruces example is a valid example, it is essentially
> the same as List< E >. Both Bruce's example and List could
> be written without generics and use covarient return types
> instead, but by generifting the interface it is easier to
> use.

It is not the same at all. List<E> allows for any declaration to specify any type it wants. Bruce's example is only allowing a single type. The other difference is that a method with a generic parameter supports overloading with a more specific argument type while plain Java classes do not.

> Perhaps if Bruce expanded the example and contrasted the
> generic with the non-generic version you would be happier
> with his code.

Not really. Generics are not necessary to achieve the stated purpose in the example. If a developer only wants to fufill that purpose and nothing else, they should not introduce the added complexity of generics. Don't swat flies with a sledgehammer.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Use cases for Generics

Posted: Nov 10, 2005 7:36 AM

> To me the type system is doing exactly the right thing;

Did I say it wasn't?

> your examples are asymmetric with respect to the types, so
> some examples work and not others. But if you change the
> code to be symmetric with respect to the types then you
> get symmetric results.

Did you think I was unaware of this? If I didn't understand this, how would I understand the problem with asymmetry?

> {snip}
> Then both cases will work. You have said "Generally that's
> what you want to do" when refering to this symmetry.

Yes. Asymmetry of this kind is almost always to be avoided. It can cause unexpected behavior. See the Comparable API and the Object.equals API for more info.

> So
> perhaps if that is the behaviour you wanted for A you
> could code A, B, and C as:
> class A< T extends A > implements Comparable< A > {
> public final int compareTo( final A notUsed ) { return
> urn 0; }
> }

You are missing the point. If that's what is wanted, there is no issue. The issue comes when you want so-called 'self-types'. That is, a type whose parameteric type is itself. There is no way to enforce self-types in the current generic implementation. The other problem with self-types is that they are confusing to a lot of developers. All I am suggesting is that Bruce have a short discussion about what a declaration like the following means:

class A<T extends A>

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Use cases for Generics

Posted: Nov 10, 2005 7:42 AM

> I should have been more precise. "Covariant return types"
> are as you describe them. However, the term covariant
> applies to a broader range of issues. For example, here:
> http://www.developertutorials.com/tutorials/java/java-theor
> y-generic-050323/page2.html

True, I have no argument there. But the Java language designers have chosen to use them in specific ways (similar to 'reference'.) It seems better to use the Java-specific terms in a book about Java.

> Brian Goetz explains how arrays in Java are covariant,
> whereas generics are not (without using wildcards).

And that's perfectly aceptable in a book about language design. If I am reading your book and start using the terms in the book, I would want them to sync-up with the rest of the Java community. People who are going to read this book are generally not going to be experts. They will be beginner or intermediate Java developers.

Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Re: Use cases for Generics

Posted: Nov 10, 2005 8:53 AM

> True, I have no argument there. But the Java language
> designers have chosen to use them in specific ways
> (similar to 'reference'.) It seems better to use the
> Java-specific terms in a book about Java.

This sounds like yet another case where the Java designers have decided to invent a new meaning for an existing term, something I find endlessly frustruating. It smacks of the worst kind of hubris, that they can say "let's choose to use this term differently." One of the worst was when they called the use of getters and setters a "design pattern," but there are plenty of other examples. The question I have is: do I use the term that the rest of the computer science community already understands, or do I use the made-up meaning that the Java language designers have decided to attach to it. Because they are too lazy to be precise, it doubles the amount of work I have to do.

My inclination is to try to use the term as it was originally understood in the computer science community. I'm trying to teach Java in the context of computer science. I'd rather people understood the larger issues, so they could go to another language and see the similarities, rather than understanding the corner issues of one language and be confused when faced with the larger world. Otherwise, why use a term at all? Why not just say "here's what Java does," rather than pretending that it's a generally understood concept?

It's hard enough to try to get terms right without them making up new meanings when it's too much trouble to learn about them.

</rant>

Howard Lovatt

Posts: 321
Nickname: hlovatt
Registered: Mar, 2003

Re: Use cases for Generics

Posted: Nov 10, 2005 2:57 PM

@James Watson,

You should perhaps take a look at this discussion:

http://www.artima.com/forums/flat.jsp?forum=106&thread=135896

The topic of self-types is covered here.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Use cases for Generics

Posted: Nov 11, 2005 6:37 AM

> My inclination is to try to use the term as it was
> originally understood in the computer science community.
> I'm trying to teach Java in the context of computer
> science. I'd rather people understood the larger issues,
> so they could go to another language and see the
> similarities, rather than understanding the corner issues
> of one language and be confused when faced with the larger
> world. Otherwise, why use a term at all? Why not just say
> "here's what Java does," rather than pretending that it's
> a generally understood concept?

You've got a good point here. Maybe a note explaining the discrepancies would suffice.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Use cases for Generics

Posted: Nov 11, 2005 6:59 AM

In that thread you give the following example:

abstract class HasF< T extends HasF< T > > {
    abstract T fClass();
    @SuppressWarnings( "unchecked" ) T f() {
        System.out.println( "HasF.f()" );
        return (T)this;
    }
}

And write this:

"The difference between f and fClass is the cast in f. This is because of the lack of a MyType in Java as Jay Sachs has pointed out (but note it is not associated with erasure - both Pizza and Scala that have MyType use erasure). The problem is that Java takes this to be of type HasF whereas in fact it is of type extends HasF, which because of the recursive definition of T is T, and hence the cast won't fail (it is just that Java doesn't know it won't fail!)."

Are you saying that the cast in f() can never fail? If so you are making the exact mistake that I am trying to describe. THe cast in f() doesn't (ever?) fail, but that's because of erasure only. The following code demonstrates that this is not guaranteed to be of type T:

public class Test
{
    public static void main(String[] args)
    {
        A a = new B().f();
        //B b = new B().f(); does not compile
    }
}
 
abstract class HasF< T extends HasF< T > > {
    @SuppressWarnings( "unchecked" ) 
    T f() {
        System.out.println( "HasF.f()" );
        return (T)this;
    }
}
 
class A extends HasF<A>
{
}
 
class B extends HasF<A>
{
}

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Use cases for Generics

Posted: Nov 11, 2005 7:01 AM

> In that thread you give the following example:

http://www.artima.com/forums/flat.jsp?forum=106&thread=135896

Brice Beard

Posts: 1
Nickname: bricou
Registered: Dec, 2005

Re: Use cases for Generics

Posted: Dec 6, 2005 5:46 AM

Late reply, not sure if you covered this:

interface Constrained<T extends MyType>
{
void constrainedClass(Class<T> class);
Class<T> getType();
}

ensures constrained link between generic type and class hierarchy.

Mo Welch

Posts: 2
Nickname: mjjava
Registered: Jan, 2006

Re: Use cases for Generics

Posted: Jan 12, 2006 10:59 AM

I've looked at your lists; and quite frankly, I have no idea of what your talking about!!! And this is the case I find with
most students who first encounter generics (and the old system of enumerations). So how about an example to get the point across. Take, as an example, the hundreds of thousands of teachers who use a grading system of A,B,C,D,F and I(for incomplete). How do you separate these letters from the regular use of the standard alphabet in writing up a program to keep track of grades? Probably, one could try and use generics - maybe you could try and show us how.

regards,
mjjava

Flat View: This topic has 39 replies on 3 pages [ « | 1 2 3 ]

Previous Topic

Next Topic