www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [Proposal] "Name inference" for function templates

reply "Andrei Khropov" <andkhropov nospam_mtu-net.ru> writes:
I think retyping the same name twice for function templates is not a very
natural way, so I propose omitting the template name if there's only a single
declaration in the template's body and then this declaration's name is
"inferred " for subsequent use, i.e. :

------------------------------------------------
template sqr(T)
{
	T sqr( T x )
	{
		return x*x;
	}
}
------------------------------------------------

could be replaced by

------------------------------------------------
template(T)
{
	T sqr( T x )
	{
		return x*x;
	}
}
------------------------------------------------

The usage is as usual:

------------------------------------------
int main( char[][] args )
{
    writefln("sqr(5) returns %d", sqr(5) );
    return 0;
}
------------------------------------------

This syntax also looks familiar to C++ guys ;-).

The only obstacle I see is that it may somewhat complicate the compiler.

-- 
AKhropov
Jun 15 2006
next sibling parent reply Markus Dangl <danglm in.tum.de> writes:
Andrei Khropov schrieb:

 I think retyping the same name twice for function templates is not a very
 natural way, so I propose omitting the template name if there's only a single
 declaration in the template's body and then this declaration's name is
 "inferred " for subsequent use, i.e. :
 ------------------------------------------------
 template sqr(T)
 {
 	T sqr( T x )
 	{
 		return x*x;
 	}
 }
 ------------------------------------------------


http://www.digitalmars.com/d/template.html
If there's only a single declaration, you can even write:

T sqr(T) ( T x )
{
     return x*x;
}

Which is already in the language and even shorter than your proposal ;)
This is the same for class templates.
Jun 15 2006
next sibling parent reply Sean Kelly <sean f4.ca> writes:
Markus Dangl wrote:

 
 http://www.digitalmars.com/d/template.html
 If there's only a single declaration, you can even write:
 
 T sqr(T) ( T x )
 {
     return x*x;
 }
 
 Which is already in the language and even shorter than your proposal ;)
 This is the same for class templates.


Huh.  I don't see any mention of that syntax being legal in the docs, 
but it works.  And to think I wanted to propose this a while back--I 
should have just tried it out. :-)


Sean
Jun 15 2006
parent reply Markus Dangl <danglm in.tum.de> writes:
 Huh.  I don't see any mention of that syntax being legal in the docs, 
 but it works.  And to think I wanted to propose this a while back--I 
 should have just tried it out. :-)


Whoops, i read the wrong part of the doc and used it accidently for 
function templates - now that you mentioned it i read through the docs 
again and it's not there ;)
Jun 16 2006
parent "Andrei Khropov" <andkhropov nospam_mtu-net.ru> writes:
Markus Dangl wrote:


 Huh.  I don't see any mention of that syntax being legal in the docs,  but
 it works.  And to think I wanted to propose this a while back--I  should
 have just tried it out. :-)


 
 Whoops, i read the wrong part of the doc and used it accidently for function
 templates - now that you mentioned it i read through the docs again and it's
 not there ;)


D Easter eggs? <g>

-- 
AKhropov
Jun 16 2006
prev sibling next sibling parent Derek Parnell <derek psych.ward> writes:
On Fri, 16 Jun 2006 04:35:57 +0200, Markus Dangl wrote:


 http://www.digitalmars.com/d/template.html
 If there's only a single declaration, you can even write:
 
 T sqr(T) ( T x )
 {
      return x*x;
 }
 



 This is the same for class templates.


Neat! But it is not documented. 

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
16/06/2006 1:34:48 PM
Jun 15 2006
prev sibling next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Markus Dangl wrote:

 Andrei Khropov schrieb:

 I think retyping the same name twice for function templates is not a very
 natural way, so I propose omitting the template name if there's only a
 single
 declaration in the template's body and then this declaration's name is
 "inferred " for subsequent use, i.e. :
 ------------------------------------------------
 template sqr(T)
 {
     T sqr( T x )
     {
         return x*x;
     }
 }
 ------------------------------------------------


 
 http://www.digitalmars.com/d/template.html
 If there's only a single declaration, you can even write:
 
 T sqr(T) ( T x )
 {
     return x*x;
 }
 
 Which is already in the language and even shorter than your proposal ;)
 This is the same for class templates.



_<  When did THAT get added?  And why didn't I notice?!


<sob>  All those extra lines of code... all that extra typing... makes
you wonder how much of D we don't actually know about :P

	-- Daniel

-- 
Unlike Knuth, I have neither proven or tried the above; it may not even
make sense.

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D
i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/
Jun 16 2006
parent Don Clugston <dac nospam.com.au> writes:
Daniel Keep wrote:

 
 Markus Dangl wrote:

 Andrei Khropov schrieb:

 I think retyping the same name twice for function templates is not a very
 natural way, so I propose omitting the template name if there's only a
 single
 declaration in the template's body and then this declaration's name is
 "inferred " for subsequent use, i.e. :
 ------------------------------------------------
 template sqr(T)
 {
     T sqr( T x )
     {
         return x*x;
     }
 }
 ------------------------------------------------


 http://www.digitalmars.com/d/template.html
 If there's only a single declaration, you can even write:

 T sqr(T) ( T x )
 {
     return x*x;
 }

 Which is already in the language and even shorter than your proposal ;)
 This is the same for class templates.


 

 _<  When did THAT get added?  And why didn't I notice?!


 
 <sob>  All those extra lines of code... all that extra typing... makes
 you wonder how much of D we don't actually know about :P


More than any of us can possibly imagine, I believe. Including Walter.
I just discovered that

int mult(int x)(int y)
{
      return x*y;
}

also works. The first parameter is a compile-time constant, the second 
is a variable.

int q = mult!(5)(z);

IMHO, not very intuitive. But interesting.
Jun 16 2006
prev sibling next sibling parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Markus Dangl wrote:

 Andrei Khropov schrieb:
 

 I think retyping the same name twice for function templates is not a very
 natural way, so I propose omitting the template name if there's only a 
 single
 declaration in the template's body and then this declaration's name is
 "inferred " for subsequent use, i.e. :
 ------------------------------------------------
 template sqr(T)
 {
     T sqr( T x )
     {
         return x*x;
     }
 }
 ------------------------------------------------


 
 
 http://www.digitalmars.com/d/template.html
 If there's only a single declaration, you can even write:
 
 T sqr(T) ( T x )
 {
     return x*x;
 }
 
 Which is already in the language and even shorter than your proposal ;)
 This is the same for class templates.


I know for a definite fact this /did not work/ previously... must be something
that 
happened fairly recently.  A silent enhancement, perhaps just for testing
purposes for 
now?  If I can get a clear from Walter that this is a permanent feature, I am
*so* taking 
advantage of it!

-- Chris Nicholson-Sauls
Jun 16 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Chris Nicholson-Sauls wrote:

 I know for a definite fact this /did not work/ previously... must be 
 something that happened fairly recently.  A silent enhancement, perhaps 
 just for testing purposes for now?  If I can get a clear from Walter 
 that this is a permanent feature, I am *so* taking advantage of it!


I wanted to try it out. It does seem to be an attractive solution. The 
idea is to make it work as simply as class templates.
Jun 18 2006
parent Sjoerd van Leent <svanleent gmail.com> writes:
Walter Bright schreef:

 
 I wanted to try it out. It does seem to be an attractive solution. The 
 idea is to make it work as simply as class templates.


He wanted to try it out, putting in new features without us knowing it. 
Nice thing anyway Walter.
Jun 18 2006
prev sibling next sibling parent reply "Andrei Khropov" <andkhropov nospam_mtu-net.ru> writes:
Markus Dangl wrote:


 Andrei Khropov schrieb:

 I think retyping the same name twice for function templates is not a very
 natural way, so I propose omitting the template name if there's only a
 single declaration in the template's body and then this declaration's name
 is "inferred " for subsequent use, i.e. :
 ------------------------------------------------
 template sqr(T)
 {
 	T sqr( T x )
 	{
 		return x*x;
 	}
 }
 ------------------------------------------------


 
 http://www.digitalmars.com/d/template.html
 If there's only a single declaration, you can even write:
 
 T sqr(T) ( T x )
 {
     return x*x;
 }
 
 Which is already in the language and even shorter than your proposal ;)
 This is the same for class templates.


Well, besides that it isn't documented (as far as I can see)
I think it's rather confusing 
(two sequential pairs of parameters in parentheses - I a more complicated case
you really don't tell whether it is template or not at the first glance).
It's different from the class case where parameter list in parentheses in
umabiguous.

I've thought of that variant too but it seems to me that it's less readable.

Another variant maybe is to insert "!" before template parameters list in a
declaration too:

----------------------------
T sqr!(T) ( T x )
{
     return x*x;
}
----------------------------

-- 
AKhropov
Jun 16 2006
parent Rémy Mouëza <Rémy_member pathlink.com> writes:
 
 http://www.digitalmars.com/d/template.html
 If there's only a single declaration, you can even write:
 
 T sqr(T) ( T x )
 {
     return x*x;
 }
 
 Which is already in the language and even shorter than your proposal ;)
 This is the same for class templates.


Well, besides that it isn't documented (as far as I can see)
I think it's rather confusing 
(two sequential pairs of parameters in parentheses - I a more complicated case
you really don't tell whether it is template or not at the first glance).
It's different from the class case where parameter list in parentheses in
umabiguous.

I've thought of that variant too but it seems to me that it's less readable.

Another variant maybe is to insert "!" before template parameters list in a
declaration too:

----------------------------
T sqr!(T) ( T x )
{
     return x*x;
}
----------------------------

-- 
AKhropov


The "identifier!( T )" syntax is used for instanciating templates. Personnally,
I think it might be a little bit confusing in a declaration. What about making
it look like a parameterized argument list, by just moving the place where stand
the "!" or use an other, more recognizable symbol ?
T sqr ( T )!( T x ) { return x * x ; }
T sqr ( T ):( T x ) ...
T sqr:( T ) ( T x ) ...

Of course, those syntax proposal are suggestion for people who, unlike me, are
not yet satisfied with the current syntax.
Jun 17 2006
prev sibling parent Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Markus Dangl wrote:

 Andrei Khropov schrieb:

 I think retyping the same name twice for function templates is not a very
 natural way, so I propose omitting the template name if there's only a 
 single
 declaration in the template's body and then this declaration's name is
 "inferred " for subsequent use, i.e. :
 ------------------------------------------------
 template sqr(T)
 {
     T sqr( T x )
     {
         return x*x;
     }
 }
 ------------------------------------------------


 
 http://www.digitalmars.com/d/template.html
 If there's only a single declaration, you can even write:
 
 T sqr(T) ( T x )
 {
     return x*x;
 }
 
 Which is already in the language and even shorter than your proposal ;)
 This is the same for class templates.


"You found a Secret!"
Hehe..
I didn't think that would work either.

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jun 17 2006
prev sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Andrei Khropov wrote:

 ------------------------------------------------
 template(T)
 {
 	T sqr( T x )
 	{
 		return x*x;
 	}
 }
 ------------------------------------------------


[snip]

 
 This syntax also looks familiar to C++ guys ;-).


If you're going in that direction, you might want to also make the outer 
braces optional in this case, as they don't really add anything.

template(T) T sqr( T x )
{
	return x*x;
}

I think this would look cleaner, as well as even *more* familiar to 
people used to C++.
Jun 16 2006
parent reply Sean Fritz <Sean_member pathlink.com> writes:
In article <e6u86a$226k$1 digitaldaemon.com>, Frits van Bommel says...

Andrei Khropov wrote:

 ------------------------------------------------
 template(T)
 {
 	T sqr( T x )
 	{
 		return x*x;
 	}
 }
 ------------------------------------------------


[snip]

 
 This syntax also looks familiar to C++ guys ;-).


If you're going in that direction, you might want to also make the outer 
braces optional in this case, as they don't really add anything.

template(T) T sqr( T x )
{
	return x*x;
}

I think this would look cleaner, as well as even *more* familiar to 
people used to C++.


I dislike like this as it explicitly introduces the template parameter throught
the redundant word "template" (this is one of my dislikes of C++ templates - the
massive code bloat they introduce).  The current syntax:


 T sqr(T) ( T x )
 {
     return x*x;
 }


Is the way Java Generics do it, and there is no problem parsing it, as it also
explicitly introduces T, but there may be arguments made that sqr(T)(T x) is
harder to read because it depends on context instead of explicit declaration.
The context is a bit harder to notice in this case due to using () as template
delimiters instead of &lt; &gt;.

Sean
Jun 16 2006
next sibling parent James Dunne <james.jdunne gmail.com> writes:
Sean Fritz wrote:

 In article <e6u86a$226k$1 digitaldaemon.com>, Frits van Bommel says...
 

Andrei Khropov wrote:


------------------------------------------------
template(T)
{
	T sqr( T x )
	{
		return x*x;
	}
}
------------------------------------------------


[snip]


This syntax also looks familiar to C++ guys ;-).


If you're going in that direction, you might want to also make the outer 
braces optional in this case, as they don't really add anything.

template(T) T sqr( T x )
{
	return x*x;
}

I think this would look cleaner, as well as even *more* familiar to 
people used to C++.


 
 
 I dislike like this as it explicitly introduces the template parameter throught
 the redundant word "template" (this is one of my dislikes of C++ templates -
the
 massive code bloat they introduce).  The current syntax:
 
 

T sqr(T) ( T x )
{
    return x*x;
}


 
 
 Is the way Java Generics do it, and there is no problem parsing it, as it also
 explicitly introduces T, but there may be arguments made that sqr(T)(T x) is
 harder to read because it depends on context instead of explicit declaration.
 The context is a bit harder to notice in this case due to using () as template
 delimiters instead of &lt; &gt;.
 
 Sean
 
 


For my own research language I've adopted a mixture of Pascal and D 
syntax and I have to say I really like it:

// Generic function to add two 'T's and return a 'T':
function(T) addtwo(a, b : T) : T
{
	return a + b;
}

You get the 'function' keyword which is a great way to introduce 
additional syntaxes like generics support (T); it also looks readable, 
clear, and concise.  But that is just my opinion.

-- 
James Dunne
Jun 16 2006
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Sean Fritz wrote:

 T sqr(T) ( T x )
 {
     return x*x;
 }


 
 Is the way Java Generics do it,


I didn't think Java supported function templates (only class templates).


 and there is no problem parsing it,


That's true, although it requires arbitrary lookahead, which isn't a 
significant problem.


 as it also
 explicitly introduces T, but there may be arguments made that sqr(T)(T x) is
 harder to read because it depends on context instead of explicit declaration.
 The context is a bit harder to notice in this case due to using () as template
 delimiters instead of &lt; &gt;.


The < and > cause a lot more ambiguity problems than they solve.
Jun 18 2006
parent reply Sean Fritz <Sean_member pathlink.com> writes:
In article <e7346j$1uo9$2 digitaldaemon.com>, Walter Bright says...

Sean Fritz wrote:

 T sqr(T) ( T x )
 {
     return x*x;
 }


 
 Is the way Java Generics do it,


I didn't think Java supported function templates (only class templates).


Yes, there are class and method level generics.  There are none of the linking
issues that come up from function templates (thank gods!).

Class generics are (of course):

class Foo<T> {  ... }

While method generics are:

public void <T> T[] toArray(T[] arr) { ... }

The distinction in placment of the type parameter is one of the weirdest
syntactical choices in Java.  It doesn't take long to master, but it constantly
leaves you wondering why they did it.

Also, they aren't really anything like templates except that they allow generic
programming.  It really takes several months to fully grok generics (especially
with the Java Language Spec being the only decent reference at the moment).

Sean
Jun 18 2006
next sibling parent Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Sean Fritz wrote:

 
 While method generics are:
 
 public void <T> T[] toArray(T[] arr) { ... }
 


Nope, it's either:
   public <T> T[] toArray(T[] arr) { ... }
or:
   public <T> void toArray(T[] arr) { ... }

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jun 18 2006
prev sibling parent reply Dave <Dave_member pathlink.com> writes:
Sean Fritz wrote:

 In article <e7346j$1uo9$2 digitaldaemon.com>, Walter Bright says...

 Sean Fritz wrote:

 T sqr(T) ( T x )
 {
     return x*x;
 }


 Is the way Java Generics do it,


 I didn't think Java supported function templates (only class templates).


 
 Yes, there are class and method level generics.  There are none of the linking
 issues that come up from function templates (thank gods!).
 
 Class generics are (of course):
 
 class Foo<T> {  ... }
 
 While method generics are:
 
 public void <T> T[] toArray(T[] arr) { ... }
 


So let's say we want to implement a generic sqr method in Java... How 
would we do it? I came up w/ this after just a quick look at the spec. 
to get the syntax right:

public class Test
{
	public static void main(String args[])
	{
		Integer i = 100;
		System.out.println(sqr(i));
		int j = 1000;
		System.out.println(sqr(j));
	}
	public static <T> T sqr(T x)
	{
		return x * x;
	}
}

However, I get this when I compile:

Test.java:10: operator * cannot be applied to T,T
                 return x * x;

?

Thanks,

- Dave


 The distinction in placment of the type parameter is one of the weirdest
 syntactical choices in Java.  It doesn't take long to master, but it constantly
 leaves you wondering why they did it.
 
 Also, they aren't really anything like templates except that they allow generic
 programming.  It really takes several months to fully grok generics (especially
 with the Java Language Spec being the only decent reference at the moment).
 
 Sean
Jun 18 2006
next sibling parent reply Sjoerd van Leent <svanleent gmail.com> writes:
Dave wrote:

 
 public class Test
 {
     public static void main(String args[])
     {
         Integer i = 100;
         System.out.println(sqr(i));
         int j = 1000;
         System.out.println(sqr(j));
     }
     public static <T> T sqr(T x)
     {
         return x * x;
     }
 }
 
 However, I get this when I compile:
 
 Test.java:10: operator * cannot be applied to T,T
                 return x * x;
 
 ?
 
 Thanks,
 
 - Dave



This is correct behaviour. You are now stating:

T must be of type Object. Type object doesn't have the * operator 
implemented. Even extending it from Number won't help, since the * 
operator doesn't work on class instances, only on primitives. To get it 
work you need quite a hack:

package generic.test;

import sun.reflect.generics.reflectiveObjects.NotImplementedException;

public class Test {
     public static void main(String args[]) {
         Integer i = 100;
         System.out.println(sqr(i));
         int j = 1000;
         System.out.println(sqr(j));
     }
     public static <T extends Number> T sqr(T x) {
     	if(x instanceof Integer) {
     		return (T)(Number)new Integer(x.intValue() * x.intValue());
     	} else if(x instanceof Byte) {
     		return (T)(Number)new Byte((byte)(x.byteValue() * x.byteValue()));
     	} else if(x instanceof Long) {
     		return (T)(Number)new Long(x.longValue() * x.longValue());
     	} else if(x instanceof Double) {
     		return (T)(Number)new Double(x.doubleValue() * x.doubleValue());
     	} else if(x instanceof Float) {
     		return (T)(Number)new Float(x.floatValue() * x.floatValue());
     	} else {
     		throw new NotImplementedException();
     	}
     }
}

Which is, if you ask me, not the best way of using Generics, well, I 
didn't invent them in Java, and it shows that it is really syntactic sugar.

Regards,
Sjoerd
Jun 18 2006
next sibling parent Dave <Dave_member pathlink.com> writes:
Sjoerd van Leent wrote:

 Dave wrote:

 public class Test
 {
     public static void main(String args[])
     {
         Integer i = 100;
         System.out.println(sqr(i));
         int j = 1000;
         System.out.println(sqr(j));
     }
     public static <T> T sqr(T x)
     {
         return x * x;
     }
 }

 However, I get this when I compile:

 Test.java:10: operator * cannot be applied to T,T
                 return x * x;

 ?

 Thanks,

 - Dave


 
 
 This is correct behaviour. You are now stating:
 
 T must be of type Object. Type object doesn't have the * operator 
 implemented. Even extending it from Number won't help, since the * 
 operator doesn't work on class instances, only on primitives. To get it 
 work you need quite a hack:
 
 package generic.test;
 
 import sun.reflect.generics.reflectiveObjects.NotImplementedException;
 
 public class Test {
     public static void main(String args[]) {
         Integer i = 100;
         System.out.println(sqr(i));
         int j = 1000;
         System.out.println(sqr(j));
     }
     public static <T extends Number> T sqr(T x) {
         if(x instanceof Integer) {
             return (T)(Number)new Integer(x.intValue() * x.intValue());
         } else if(x instanceof Byte) {
             return (T)(Number)new Byte((byte)(x.byteValue() * 
 x.byteValue()));
         } else if(x instanceof Long) {
             return (T)(Number)new Long(x.longValue() * x.longValue());
         } else if(x instanceof Double) {
             return (T)(Number)new Double(x.doubleValue() * 
 x.doubleValue());
         } else if(x instanceof Float) {
             return (T)(Number)new Float(x.floatValue() * x.floatValue());
         } else {
             throw new NotImplementedException();
         }
     }
 }
 
 Which is, if you ask me, not the best way of using Generics, well, I 
 didn't invent them in Java, and it shows that it is really syntactic sugar.
 
 Regards,
 Sjoerd


Yikes! :)
Jun 18 2006
prev sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Sjoerd van Leent wrote:

 Dave wrote:

 public class Test
 {
     public static void main(String args[])
     {
         Integer i = 100;
         System.out.println(sqr(i));
         int j = 1000;
         System.out.println(sqr(j));
     }
     public static <T> T sqr(T x)
     {
         return x * x;
     }
 }

 However, I get this when I compile:

 Test.java:10: operator * cannot be applied to T,T
                 return x * x;

 ?

 Thanks,

 - Dave


 
 
 This is correct behaviour. You are now stating:
 
 T must be of type Object. Type object doesn't have the * operator
 implemented. Even extending it from Number won't help, since the *
 operator doesn't work on class instances, only on primitives. To get it
 work you need quite a hack:
 
 package generic.test;
 
 import sun.reflect.generics.reflectiveObjects.NotImplementedException;
 
 public class Test {
     public static void main(String args[]) {
         Integer i = 100;
         System.out.println(sqr(i));
         int j = 1000;
         System.out.println(sqr(j));
     }
     public static <T extends Number> T sqr(T x) {
         if(x instanceof Integer) {
             return (T)(Number)new Integer(x.intValue() * x.intValue());
         } else if(x instanceof Byte) {
             return (T)(Number)new Byte((byte)(x.byteValue() *
 x.byteValue()));
         } else if(x instanceof Long) {
             return (T)(Number)new Long(x.longValue() * x.longValue());
         } else if(x instanceof Double) {
             return (T)(Number)new Double(x.doubleValue() *
 x.doubleValue());
         } else if(x instanceof Float) {
             return (T)(Number)new Float(x.floatValue() * x.floatValue());
         } else {
             throw new NotImplementedException();
         }
     }
 }
 
 Which is, if you ask me, not the best way of using Generics, well, I
 didn't invent them in Java, and it shows that it is really syntactic sugar.
 
 Regards,
 Sjoerd


Aah, "generics"...

I remember a fairly important language person (obviously can't remember
the damn name *grumble*) was having a go at .NET 2.0's generics for
exactly the same reason.

This basically cripples generics in both Java and .NET since it makes
them utterly useless for any kind of numerical work: there are no
interfaces or base classes for arithmetic operations, which is a
complete pain in the arse.

Generics in .NET and Java should really be called Object Generics, since
it's all but useless for basic types.

Of course, D doesn't suffer this problem because its templates simply
get expanded until it becomes clear that it can't be done, and THEN it
fails.  .NET and Java seem to treat templates more like compile-time
object casting.

I suppose the one advantage that .NET has over Java *and* C++/D is that
its templates are compiled without being expanded first.  This means
that arbitrary libraries can come along and instantiate the templates,
even without the source code.  AFAIK, Java does what C++ and D do, which
is to expand all the templates on compilation.

Ah well.  Not our problem, after all :)  Just another wart to add to
Java's list ^_^

	-- Daniel

-- 
Unlike Knuth, I have neither proven or tried the above; it may not even
make sense.

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D
i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/
Jun 18 2006
next sibling parent xs0 <xs0 xs0.com> writes:
 I suppose the one advantage that .NET has over Java *and* C++/D is that
 its templates are compiled without being expanded first.  This means
 that arbitrary libraries can come along and instantiate the templates,
 even without the source code.  AFAIK, Java does what C++ and D do, which
 is to expand all the templates on compilation.


Actually, Java doesn't do any expansion at all - all the generic type 
information is in fact lost upon compilation (so-called "type erasure") 
and the only purpose generics have is improved type safety in source - 
you can now finally read/write what a container is supposed to contain..


xs0
Jun 19 2006
prev sibling next sibling parent Mike Parker <aldacron71 yahoo.com> writes:
Daniel Keep wrote:


 Generics in .NET and Java should really be called Object Generics, since
 it's all but useless for basic types.


They call it Generics and not templates for a reason, methinks. I know 

C++/D at all. For now, the implementation does little more than ensure 
type-safety at compile time and handle class casts and autoboxing behind 
the scenes so that you don't have to.

This is one thing, among many, that trips up a lot of C++ programmers 
when they come to Java. Generics are not templates, the usual operators 
can't be used on objects (except that String allows + for 
concatenation), and what have you. Because of this, someone very 
experienced in C++ is not going to be a good Java programmer without a 
lot of time and patience. Most don't bother. The languages have two 
different paradigms and you just can't attack the same problem the same 
way. There was some grumbling in the Java community when Generics were 
first introduced, but once people got comfortable with it the noise 
settled down. It's really better having them than not, though there are 
still a few week points.

If you ask a Java programmer what Java's warts are, they'll give you a 
nice long list, but it's going to be very different from the list a C++ 
programmer would give for the same question. What C++ programmers 
consider Java warts, many Java programmers see as strengths. It's a 
different language with a very different paradigm. Java is from Venus 
and C++ is from Mars.

The thing about D is that it lives on Mars, too, but it's like the first 
generation child of immigrants from Venus. I think that's why both Java 
and C++ programmers can get comfortable with it. They can each find 
something of their own cultures. I'll take Java over C++ any day of the 
week for most tasks. But D kicks them both in the teeth.
Jun 19 2006
prev sibling parent Sean Fritz <Sean_member pathlink.com> writes:
In article <e7583j$2drm$1 digitaldaemon.com>, Daniel Keep says...

I suppose the one advantage that .NET has over Java *and* C++/D is that
its templates are compiled without being expanded first.  This means
that arbitrary libraries can come along and instantiate the templates,
even without the source code.  AFAIK, Java does what C++ and D do, which
is to expand all the templates on compilation.


This is incorrect.  It is even more complicated than that.  Generics are
compiled <i>away</i> at compile time and the only thing left at runtime is the
erasure (which is the least specific class that represents the type).

Generics have very little to do with templates, and to treat them as such is
simply going to lead to frustration.  You are correct in saying they are mostly
for compile time casting, because that's exactly what they do.  A different goal
than C++ templates.
Jun 20 2006
prev sibling parent Sean Fritz <Sean_member pathlink.com> writes:
In article <e747sa$nn9$1 digitaldaemon.com>, Dave says...

So let's say we want to implement a generic sqr method in Java... How 
would we do it? I came up w/ this after just a quick look at the spec. 
to get the syntax right:

public class Test
{
	public static <T> T sqr(T x)
	{
		return x * x;
	}
}


Java Generics are typesafe, you must bound the type with something that
implements multiply().

public class Test {
public static <T extends Multiplyable<T>> T sqr(T x) {
return x.multiply(x);
}
}

Assuming multiplyable is a generic interface that takes a type paramter.
Jun 20 2006