[OT: TRILUG, OnTopic: JUG] Re: [TriLUG] C# and .NET

Andrew C. Oliver acoliver at apache.org
Mon Jul 1 16:58:56 EDT 2002


(sorry to those who get this twice, but it seems to be boiling over into

>Andrew, from your response it doesn't look like you understand
>C++ templates.  C++ templates happen strictly at compile time
>too.  There is no form of "run-time" templates anywhere in
>C++.  What is it about "compile-time" generics you have a problem
>with?
>  
>
*sigh* - yes I understand that in C++ they are compile-time.  Yes I 
understand C++ and yes I like
templates and have used them significantly in the past.  I also 
understand that Java Generics does not
provide to Java 1-1 what they do to C++.  By the nature of the lanugage, 
while EVERYTHING in C++
is compile time (more or less) that does not mean the same thing should 
be compile-time in Java.  Java
Generics should not be compile-time.  

(the sigh was at the fact I get tired of "gee if you don't like it you 
must not understand it")

>About support for "primitive types".  Why will it not
>support them?  If not, then *that* does severely limit them.
>But, then again, one of my biggest grips with java is it's
>lack of a typedef operator, so oh well...
>  
>
As to why it won't support them, it has largely to do with the fact that 
they'll be compile-time (now you're
getting at the crux of the issue).  You cannot have a int$1.class 
because int is not a class.  (And hence the core
of why they should not be compile-time).  Because of the way Java works, 
while compile-time is appropriate
here for C++, this shows quite easily why it is not necessarily 
appropriate in this area for Java.

The Second rationale on why it won't support primitives, is even if it 
expanded the code to wrap "int" in Integer, there
would be the same performance -- as just having the programmer doing the 
same "boxing/unboxing" manually.

(I'm explaining the rationale.....this is not "I agree with it" -- and 
yes I understand...but do not disagree it)

complete agreement on "typedef".

>Also, does it support templates of templates?  Partial specialization?
>While that is a part of C++ that is a bit difficult to understand,
>it also allows templates to do very powerful stuff.
>Take a look at the Blitz library (http://www.blitz.org, iirc).
>They're using templates to get assembly like linear
>algebra performance using C++.
> 
>
And now you get into an area I do not profess to understand (notice my 
blatant admission of
"I don't understand" versus "I don't like").  I'll guess at what that 
would mean to C++

 From my admitedly partial undestanding of  "templates of templates" and 
partial "specialization", and my
good understanding of Java Generics, I would guess not.  (explanation below)

>  
>
>>So generics will be *strictly* syntax candy.
>>    
>>
>
>Syntax yes, but more than candy.  Generics (such as templates)
>allow you to spot problems at compile time rather than run
>time.  This allows better debugging (since once you get it
>running, you can then disregard a whole class of possible
>errors) and faster development.  Candy, it most assuredly
>is not.
>  
>
You're turning this argument into something I'm not arguing: against 
generics entirely.
Java needs generics but generics needs to support primitive types.  In 
Java this would
mean run-time support for generics (not just compile-time).  My argument 
is that the
proposed JSR-014 is nothing but syntax candy.  

And I would guess (although I haven't tried it) that in this 
implementation, debugging generics will most decidedly
not be an enjoyable experience.  While this is admittedly an 
oversimplification, generics will
be implemented as a:

Class containing a "magic inner class selector"
a set of implied inner classes

-- This won't match what you typed of course!

I cannot imagine that this will be straightforward to debug, perhaps it 
will be mitigated by tomorrow's
debugger.

-Andy

>Tanner
>  
>






More information about the TriLUG mailing list