Home » forums » LtU Forum

What is covariant signature transformation?

I am trying to understand STL, and I came across an interview with Alex Stepanov where he states:

Again, the signature of max is:

max: T x T -> T

It is not expressible in Java, because the inheritance from some class or interface T changes it into:

max: T' x T -> T

You need covariant signature transformation and an ability to obtain types from types, a notion of a virtual type if you like, a v-table containing type descriptors.

I am not sure what he is trying to say here. Is 'covariant signature transformation' the same as 'multidimensional subtyping', perhaps choosing an appropriate object in the class hierarchy based on more than one value?



p.s. This interview is from 2001

By Nicholas Ralabate at 2006-06-05 19:43 | LtU Forum | previous forum topic | next forum topic | other blogs | 2063 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

"STL is the result of a bacterial infection"

This Q&A from the linked interview explains a lot ;-)

Question:
What is the origin of STL? Has STL been conceived to be what it is now, that is "the" C++ Standard Library, or does it come from some other project? Could you tell us a history of STL?

Answer:
In 1976, still back in the USSR, I got a very serious case of food poisoning from eating raw fish. While in the hospital, in the state of delirium, I suddenly realized that the ability to add numbers in parallel depends on the fact that addition is associative. (So, putting it simply, STL is the result of a bacterial infection.)...

By Allan McInnes at Mon, 2006-06-05 19:51 | login or register to post comments

Try it...

Try to implement the function max, so that it returns the bigger of the two. Well, clearly, T needs to be comparable, so we make the interface, IComparable. However, what's in this interface? The method lessThan, of course! And what's the type? bool lessThan(IComparable rhs)? Err, no. Because when you implement that interface, you don't want to compare with any IComparable, but just things of the same type. There is no way to say in Java that two types need to the exactly same, not merely derived from the same thing.

By genneth at Mon, 2006-06-05 20:36 | login or register to post comments

Use generics

The interview was pre-generics. Here it is in C#:

using System;

static class TestMax {

public static T Max(T x, T y) where T : IComparable {
return (x.CompareTo(y) >= 0) ? x : y;
}

public static void Main() {
int x = Max(32, 59);
double d = Max(3.14, 2.68);
string s = Max("Java", "C#");
DateTime dt = Max(DateTime.Today, new DateTime(2007));
}
}

By AndrewKennedy at Mon, 2006-06-05 21:10 | login or register to post comments

The whole point of the

The whole point of the interview answer is to explain why Stepanov is pro-generics and somehwat anti-OO.

By Ehud Lamm at Mon, 2006-06-05 21:11 | login or register to post comments

I understand the restriction now

but I am still confused on his proposed solution:
You need covariant signature transformation and an ability to obtain types from types, a notion of a virtual type if you like, a v-table containing type descriptors.
Is he describing how STL determines a parameter's type at compile time?
Searching for "covariant signature transformation" didn't turn up anything useful.
By Nicholas Ralabate at Mon, 2006-06-05 23:32 | login or register to post comments

Why do you need both of them

Why do you need both of them to be the same type? So long as one of them knows how to compare itself with the other, I don't see any need for more restrictions.

By Curtis W at Wed, 2006-06-07 18:59 | login or register to post comments

link?

That sounds like a fun interview -- have you a link for it?

By jimdesu at Mon, 2006-06-05 20:46 | login or register to post comments

Link

Try this. It's in the OP, but not hyperlinked.

By Allan McInnes at Mon, 2006-06-05 21:08 | login or register to post comments

No warm fuzzies for OOP

Yes. STL is not object oriented. I think that object orientedness is almost as much of a hoax as Artificial Intelligence. I have yet to see an interesting piece of code that comes from these OO people.

Him and Tablizer need to get together. For reasons that are somewhat fuzzy, it's always seemed to me that OOP where everything is jammed into a class seems to introduce coupling problems which results in a lot of refactoring because it's so easy to get it wrong the first time.

Maybe that's why I've always liked CLOS-style OO better, or even Python/Ruby/Boo where you can have free-standing functions.

By Dave Lopez at Tue, 2006-06-06 15:28 | login or register to post comments