Talk:Curiously recurring template pattern

There's a Java version, too

Since Java 1.5 introduced its own implementation of generics, I've noticed a "curiously recurring generics pattern" in Java, but generally geared toward a somewhat different purpose:

 public interface Base<D extends Base<D>> {
     public D someOperation ();
     public D somethingElse (D argument);
     public void doSomethingWith (D whatever);
 }

It's even more common with abstract classes that provide a skeleton implementation, e.g.

 public abstract class Vector<D extends Vector<D>> {
     public abstract int getDimensions();
     private void checkDimensions (D other) {
         if (getDimensions() != other.getDimensions()) throw new Exception();
     }
     public D add (D other) {
         checkDimensions(other);
         return addImpl (other);
     }
     public D subtract (D other) {
         checkDimensions(other);
         return addImpl(other.negated());
     }
     public abstract D addImpl (D other);
     public abstract D negated ();
 }

where subclasses just override addImpl (and don't have to do dimension-mismatch detection) and implement negation. The use of the derived type as a parameter for the base type allows several Vector classes to share this code (don't repeat yourself is observed for things they can all do in a common way) while still accepting and returning themselves instead of some abstract type. Prior to Java 5, the pattern couldn't be used and all Vector subclasses would have to return a generic Vector and cope with a generic Vector parameter. So a Vector that was actually a polynomial function, FFT object, or whatever and another that was a plain old coordinate vector could be added with only a run-time ClassCastException to indicate there was a problem, and callers had to cast the return values. Java 5's covariant return types address the latter problem and its generics, coupled with the curiously recurring generics pattern, address the former problem.

(Polynomials, FFTs, and coordinate vectors can, mind you, be abstracted as having an array of components, perhaps in a java.util.Vector, of some length, added componentwise, but the example base class above is superior if you want addable, negatable things that don't have components -- either they don't decompose easily or naturally or they're actually the scalars used to build coordinate vectors -- or sparse representations etc.; FFTs *must* have a sparse representation of some sort, since you can't store the infinitely many coordinates needed for every sub and superharmonic of the fundamental.) —The preceding unsigned comment was added by 74.104.131.76 (talk) 02:21, 2 January 2007 (UTC).

That's a completely different thing that just looks a bit like the CRTP. There is no concept of template instantiation in Java which is what the CRTP hinges on. In the Java example you have a class Vector<D extends Vector<D>> with generic type parameter bounds that refer to the type itself, and all that does is affect which types are correct for the generic methods at compile time, whereas in C++ your class is a template instantiation where the template's type parameter refers to the derived type, meaning you generate a class which refers to its own type despite the code being defined in a template. The benefits of CRTP are not relevant to Java (e.g. there is no virtual/non-virtual distinction and all classes are reference types so there is no use for static polymorphism, and things like polymorphic copying can be done through the reflection API) 89.202.251.196 (talk) 17:16, 3 February 2017 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Curiously recurring template pattern. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20120209045146/http://www.pnotepad.org/devlog/archives/000083.html to http://www.pnotepad.org/devlog/archives/000083.html

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 15:25, 15 August 2017 (UTC)