SQL & PL/SQL

So far, I haven't seen any problem with the readability of Java's generics. Since I've never seen inside the STL, perhaps you could post a sample to show what you mean?

Since all Java classes inherit from Object and the current Collection set is using Object, it shouldn't be as messy. In c++ they have lots of methods to do different things because of the possibilities. In java we are really just concerned about converting Object to something more specific, thats straightforward.

I agree. It's reasonable want to write Matrix not ArrayList<ArrayList<Float>>.

At the end of the JSR-14 spec I remember they proposed adding some kind of typedef-like syntax, just for giving a class an alternative name. I can't find it now so maybe they've dropped the idea. Something like this:
class Matrix ArrayList<ArrayList<Float>>

Presumably you could simulate this by inheritance:
class Matrix extends ArrayList<ArrayList<Float>> {
}

Or would this have some bad implications?

Yes, STL code is often mind-bending and nearly comprehensible. But how many people need to read the source? I did because we did so in an STL class, but I never had to when I programmed STL code.

In any case, Java generics are totally different from C++ templates. Most "generic" code is no different from non-generic code. For example, the prototype compiler uses exactly the same source code for the Collections classes, just with generic class and method signatures retrofitted in. I've never seen generic Java code that resembles the puzzling STL code.

I'm going to resurrect this thread because I've been wondering about the same thing myself.
Not only is "ArrayList<ArrayList<Float>>" tedious and ugly to write everywhere, "Matrix" is far more expressive about what these kind of variables are used for than is "ArrayList<ArrayList<Float>>".

> For some reason, I haven't seen this topic come up very often, but I would think it would be fundamental to the concept. Can someone tell me why this has been left out of the spec?

> I thought of this workaround as well, but it does have the bad side effect of not making the two types equivalent (as typedef in C++ does).

ArrayList<ArrayList<Float>> base = new Matrix(); // Would work
Matrix derived = new ArrayList<ArrayList<Float>>(); // Would not work

Please note that I have a very rudimentary understanding of how generics would work. Maybe I am mistaken?

schapel wrote:

Yes, STL code is often mind-bending and nearly comprehensible. But how many people need to read the source?

People don't read STL source - they read documentation instead, for example, http://www.sgi.com/tech/stl/ In fact, the commercial implementations of STL are purposely run through an obfuscator to make the source difficult to understand. The vendors would have much preferred a link-model for templates, but that's not easily done with C++. So, they're stuck with the source-inclusion model which requires them to expose their implementation. Hence the use of obfuscation to protect their "IP".

In any case, Java generics are totally different from C++ templates.

This needs to go in a FAQ in big bold letters somewhere. With C++ templates, you can express a program that computes Netwon's method at compile-time. With Java Generics, you can safely type-cast from Object to String.

God bless,
-Toby Reyelts

Generally speaking, typedef's have had a bad reputation, because many C and C++ programmer's have abused them terribly.

If Java typedefs only worked for generic classes, I think most people would be happy, even though they would still have the potential for abuse.

God bless,
-Toby Reyelts

Even the main method can be and is horribly abused. And, as has been pointed out frequently on this forum, the whole generics mechanism has abuse potential. As long as there are bad programmers, there's going to be bad code. But since the decision to add generics has been justified for the sake of type safety, some sort of typedef should be added for the sake of readability. The generics proposal loses some of its appeal otherwise, especially since one of the stated goals of the 1.5 release is to improve code readability.
Yes, it should be much more limited than what C++ allows. Only generic types can be aliased, and only allow one level deep of aliasing (i.e. no typedefs of typedefs). This would also fit in with the requirement to keep the implementation entirely in the compiler as sort of a preprocessing directive.

Java already has a limited form of typedef -- it's called "import". And it's being extended for JDK 1.5.

Some version for generics would be nice.

The closest thing to Java's import in C++ is using, not typedef. You can use the using directive to import types or entire namespaces into the current namespace. It operates nearly identically to Java's import statement.

Typedef is different in that it creates a new name for an existing type. Java doesn't have any feature of any similarity.

God bless,
-Toby Reyelts

But the closest thing to C++'s typedef in java is import.

typedef gives a new local name to an existing entity.

import locally shortens the name of an external entity.

Logically, import for generics would not allow you to specify a new name but instead would establish defaults for the type parameters.

If you want a full new name it can be done with a class that inherits from the generic class, but this has implications at runtime. If the class is final, JIT should reduce these to nearly nothing.

A real typedef would ensure that the runtime cost would be zero -- and because of its local scope would be less prone to C++'s abuses.

Darron

You make it sound as if you're arguing to change the semantics of import as opposed to introducing a new typedef construct. I don't think that makes any sense, because they're really two different beasts which serve different purposes - as I described above.

As another example, another good way to use typedefs in C++ is as type parameters to templates.

class my_traits {
  public:
  typedef char parameter_type;
  typedef int return_type;
};

template <typename Traits> 
  Traits::return_type foo( Traits::parameter_type param );

Even though the use is different, there's nothing special about the typedef mechanism in this context - it's still the same. It's just being used to do more powerful things. I could easily see a typedef construct being used in Java to do similar things if the generics framework is improved.

God bless,
-Toby Reyelts

As I mentioned before, subclassing the generic type has polymorphism issues that I think are more serious than runtime performance.

While sitting here trying to work out some kind of syntax, though, I may have figured out why the spec has such a seemingly obvious omission. One of the stated goals of all of the 1.5 enhancements is to be non-invasive to the JVM. The idea was to implement generics entirely in the compiler, if possible. It's easy to see how ArrayList<ArrayList<Float>> could be used to generate bytecode, but I can't see how an alias for that could also be generated. What I mean is, compilation wouldn't be a problem as long as you always compiled the source file that contained the typedef. But what if you were using a typedef from a third-party library, or even one declared in another class that was already compiled? The class file could not contain that kind of information without a revision to the VM spec. Does this seem correct?

Yes, typedefs would only be local to the class.

God bless,
-Toby Reyelts

Which would hardly be more useful than no typedef at all.

That's not strictly true. There exists gobs of C++ source code that uses typedefs only for renaming ease of use local to a function or class. In the case of C++ containers which have no common parent, typedefing a container is akin to declaring your ArrayList as a Collection.

In any case, I agree that having non-local typedefs would be very useful, especially with a more powerful Generics mechanism.

God bless,
-Toby Reyelts

Ah, well, maybe in JDK 1.6....