Channel 9 - Discussions by sylvan

Coffeehouse - Interviewing programmers

sylvan — Wed, 22 Aug 2007 21:48:58 GMT

evildictaitor wrote:

In ASM a delegate is any memory length of n bits that is addressable
In C a delegate is a size_t, which is an int or long or long long depending on the processor size.
In C++ a delegate is not significantly changed from C, but it is type-checked at compile time.
In C# a delegate is a C++ function pointer which is (and I quote)
Delegates are roughly similar to function pointers in C++; however, delegates are type-safe and secure.

You can do the same trick with, for example, "a class" ("in ASM a class is a slab of memory".. etc.), doesn't make it true. A delegate, which is a C# concept, is only very superficially similar to a function pointer, but is really nothing like it. Like I explained, a delegate is a lexical closure, which is pretty isomorphic to classes (you can model one with the other). A function pointer is just a way of doing an indirect function call. Very, very different.

The fact that delegates are also type safe etc. is nice and all, but that's not the key difference.

Coffeehouse - Interviewing programmers

sylvan — Wed, 22 Aug 2007 18:22:20 GMT

AndyC wrote:

Ion Todirel wrote:

evildictaitor wrote:

*void.

good answer, you're hired

Not really, delegates are more than just function pointers. They offer type safety and security as they always point to a method, which a *void may well not do.

And above all, they capture variables (proper lexical closures, in other words)! Comparing with function pointer is useful if and only if the next sentence out of your mouth is "but they're really completely different".

Coffeehouse - Interviewing programmers

sylvan — Wed, 22 Aug 2007 18:18:07 GMT

evildictaitor wrote:

AndyC wrote:

Ion Todirel wrote:

evildictaitor wrote:

*void.

good answer, you're hired

Not really, delegates are more than just function pointers. They offer type safety and security as they always point to a method, which a *void may well not do.

The type-safety is only at compile time (for non .NET languages), so actually what a delegate is is a *void.

Even in .NET it's just a typedef wrapper on a System.IntPtr.

NO! A delegate is a tiny object that captures any variables in scope at the definition (that are also used in the definition). It's NOT anywhere close to a function pointer, it's more like a quick one-off class with a single method.

Coffeehouse - Interviewing programmers

sylvan — Wed, 22 Aug 2007 18:05:48 GMT

Dr Herbie wrote:

OK, firstly polymorphism has nothing to do with code-reuse. That's where you're confusing class inheritance with polymorphism (although you're right, polymorphism does depend on inheritance).

No, that's wrong. Value based dispatch depends on inheritance, polymorphism does not. Polymorphism does have something to do with code reuse preciesly because you can write a function that works on values of multiple types.

Here's a polymorhic method that doesn't depend on inheritance in the least:

static T pickFirst(T a, T b)
{
return a;
}

Normally this isn't very useful, you'd have to constrain the template parameter somehow (and obviously you'd do that using interfaces, and you might almost be able to claim that interfaces depend on inheritance, but that would also be wrong - consider something like Haskell that has no inheritance but manages to have a type hierarchy and polymorphism anyway; by simply using type-based dispatch rather than value-based dispatch). Consider something like

static uint length( MyList list )
{
return list.IsEmpty ? 0 : 1 + length( list.tail);
}

This is a much more useful function that does not depend on inheritance either, and would still be exceedingly polymorphic in that it can work on lists of any element type (in this case an immutable singly linked list).

So yeah, inheritance is one way of doing subtyping, but not the only way of doing polymorphism.