Re: Java Generics and Erasure foobar

Joshua Cranmer <Pidgeot18@xxxxxxxxxxxxxxx> wrote in
news:gbp3g1$e8r$1@xxxxxxxxxxxxxxxxxxxx:

HackerBob wrote:
Maybe it's me but I have been reviewing this so called major feature
of 1.5 and I cannot see the value.

I think the mistakes it detects at compile time are trivial, in that
a novice would make those mistakes. So what, if I find type issues at
runtime that's what unit testing is for. Now it takes longer to
develop <uglier> code for little to no additional value, afterall
generics get erased.

I mean if I mix a String with an Integer this will come out in unit
testing and the result will be the same. I still have to unit test, I
still have to fix the code.

I think Sun should leave the core language alone and let the
developer worry about run time exceptions from poor design and
coding.

You've not worked on large projects, I take it. The value of being
able to specify the contents of a collection is enormous. Take one
(non-Java) project I work on: it returns stuff in the form of an
enumerator, which just has a method equivalent to |Object getNext()|.
The caller is responsible for casting that to the necessary type. But
wait, what class do I cast to? Is it a card? A string? An integer? An
RDF resource?

So one of the primary features of generics is this: it's
self-documenting. You know what's in a List<String>, but List tells
you nothing about its contents. Although I personally strive to be
precise in explaining what is returned in the documentation, many
people are not that precise. After all, "returns an enumerator of all
the values" describes what it does very well, doesn't it?

Compile time safety is another vital feature. You may say "it'll come
out in unit tests," but are you really that confident that every
single line of your program is covered by enough unit tests to
validate every single possible parameter and side effect that might
happen? I doubt that your project has every single line tested let
alone with all the necessary setups to ensure that it works in all
cases.


The issue here is that you still have to code for valid scenarios. I may
not be able to test every possible scenario but I can specify/limit the
valid ones.

If you think that generics provide no value, then try writing in a
language whose notion of compile-time checking is limited to "is this
syntactically valid." Trust me, the first minor refactoring you do in
such a language will have you pining for stringent compile-time
checking. For me, this comes from actual experience, where I found a
change I had missed, despite a month of stringent testing, completely
by accident.

So generics will make your code bug proof, more bug resistant? I do not
think so. I think you find your errors sooner in the process which does
add value but not enormous.

A program is only as good as its worst piece of code. It takes but a
single statement to crash a program. The harder you make it to write
such a statement, the better off your program will be. Generics makes
it harder to write incorrect code; that alone should be sufficient
reason to use it.

I do not think making it harder to write incorrect code is the correct
goal.The goal should be to write correct code easier, more parameters
does not seem like the answer.


Overall, I understand what you are saying and I do see your point but
after years of C programming in a structured environment you learn to
declare what variables you are going to use and use them as they are
declared. Generics do not seem to be an enormous step forward, they feel
like a burden. I feel like I am forced to delcare methods and their
usage over and over. If I want a collection to be all strings I should
check that the members are an instance of type String before I add them
to the collection. This is the future so I will have to suck it up but I
do not have to like it. I think its the nature of the Java community
with shared files coming from different sources, some coded better than
others, that you need to have this type verification. I think Java is an
elegant language and as such more stringent anything is really less.


I think the short answer is that their are pros and cons to generics and
each developer will seem them differently.
.

Relevant Pages

  • Re: A Generic Generics Problem
    ... You'll get a warning at compile time, ... I suppose I'm asking for the impossible: the type safety of generics ... underlying object preserve the type information after it's created, ... List<String> always knows that it can only take a String because the ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Java Generics and Erasure foobar
    ... I think the mistakes it detects at compile time are trivial, in that a novice would make those mistakes. ... Now it takes longer to develop code for little to no additional value, afterall generics get erased. ... I mean if I mix a String with an Integer this will come out in unit testing and the result will be the same. ... You may say "it'll come out in unit tests," but are you really that confident that every single line of your program is covered by enough unit tests to validate every single possible parameter and side effect that might happen? ...
    (comp.lang.java.programmer)
  • Re: How come Ada isnt more popular?
    ... container varies, the element does not. ... The user should be able to describe string type in language terms ... but there are no generics instantiated. ... Implementation inheritance without values ...
    (comp.lang.ada)
  • Re: The Demise of C#
    ... I understand generics fine thank you. ... And please point out to me where I called myself a C++ programmer. ... > stating that both operands are going to be converted to string as ... >>> requiring explicit casts and explicitly indicating where you ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Delphi: generics coming
    ... checkable at compile time. ... Generics are compile time checkable and allow you to perform any operation ... | so far these reasons aren't compelling. ... framework types, not just lists, and that has saved us thousands of lines of ...
    (borland.public.delphi.non-technical)
Loading