light weight types

[Arne Vajhøj]

It's technically feasible, sure, but given the amount of existing Java
code when 1.5 was introduced, imagine the dumbfoundment with which a
new and incompatible set of, e.g. collections classes (and, far worse,
collection interfaces) would have been greeted.

I make the opposite conclusion from the same fact.

All the existing code resulted in a gazillion of compiler
warnings due the decision to use the same classes.

I would have preferred new classes.

Arne

 

[Arne Vajhøj]

As it stands, generics provide a compile-time contract for declarations
about type relationships. In order to get run-time behavior, i.e.,
operational use of type information you need to provide a Class object;
type parameters don't permit any run-time operations.

The result is that generics provide compile-time assertions that code
will not throw a ClassCastException or other type-related problem.
Erasure guarantees that this safety carries no run-time overhead.

No difference.

The cast is just done somewhere else in the code with type erasure.

Run-time generics would sacrifice this efficiency and tempt us to patch
holes in the type analysis with procedural hacks. Instead of analyzing
the types we'd coerce them. Java still lets you do run-time type tricks
with a type token (Class object), but type parameters are reserved for
assertions about type relationships. This forces us to deal with type
problems at compile time.

It's a well-known truth that catching and preventing bugs at compile
time is far superior to dealing with them at run time.

Generics without type erasure is not catching fewer errors at
compile time.

It has the exact same compile time type safety.

It only adds some additional capabilities in the code.

It is true that certain shortcomings exist with the erasure approach,
but the advantages make it worth it.

I don't think so.

Less functionality, no performance benefits and no stricter compile
time checks.

It is purely a compatibility issue.

Arne

 

[Mike Schilling]

As Patricia and Arne, I don't see the problem. If anything, by
overloading existing classes, they created problems for legacy code
unnecessarily.

For new code, I don't see how it would matter that the new generic
classes were an entirely new class, rather than taking advantage of
an
existing class. To the coder, it's all-new one way or the other.

What follows is largely hypothtiecal, as the only code I've written
that uses generics is really toy code intended mostly to help me use
to learn generics:

The large body of code I maintain at work has to run in 1.4
environments, so generics are not an option there. When it becomes
possible to start using 1.5 features, I'm going to do so, both in new
classes and when maintaining old classes. And the fact that I can say

List<MyClass> newList = (List<MyClass>)exisitngList; // Safe,
since I know what this list really contains
for (MyClass mc : newList)
{
...
}

will come in very handy. Modifying all the framework methods that
return currently List to return NewFangledGenericList would not have
been feasible. That is, the actual situation allows me to introduce
generics incrementally; this seems to me to be very worthwhile.

 

[Robert Klemme]

It's a well-known truth that catching and preventing bugs at compile
time is far superior to dealing with them at run time.

It does have some advantages but I do not subscribe to the general "far
superior". If that was the case then there would be no place for
dynamic languages like Ruby, Python, Perl etc. and yet there seems to be
a number of people using these languages successfully on a daily basis.
And on the other hand it seems Eiffel, which does a great deal of
compile time checks is not widely used if I'm not mistaken. Of course
there is a difference between technical superiority and wide adoption
which is often influenced by a whole number of non technical factors.
But I have come to believe that in the end the advantage of static type
checks is not dramatic.

My 0.02EUR.

Kind regards

robert

 

[Donkey Hottie]

13.10.2009 0:07, Robert Klemme kirjoitti:

It does have some advantages but I do not subscribe to the general "far
superior". If that was the case then there would be no place for dynamic
languages like Ruby, Python, Perl etc. and yet there seems to be a
number of people using these languages successfully on a daily basis.
And on the other hand it seems Eiffel, which does a great deal of
compile time checks is not widely used if I'm not mistaken. Of course
there is a difference between technical superiority and wide adoption
which is often influenced by a whole number of non technical factors.
But I have come to believe that in the end the advantage of static type
checks is not dramatic.

I personally hate "dynamic" languages like Perl, Ruby, Python..

Actually I would be very happy if Sun had implemented Java for the basis
of Ada. Object Pascal and Ada and all those are great, strongly typed
languages. Packages and all.

I have no idea why they had to take the C syntax, for a strongly typed
modular language like Java is.

And I have 20+ years of C++ experience...

 

[Arne Vajhøj]

Actually I would be very happy if Sun had implemented Java for the basis
of Ada. Object Pascal and Ada and all those are great, strongly typed
languages. Packages and all.

You could use JGnat ...

Arne