Jon Jagger (11) [Avatar] Offline
#1
I don't see why the will is like a delegate. The point about a delegate is that it turns named behaviour into unnamed behaviour. If you execute a delegate you don't know what you're executing. When the attorney (solicitor) executes your will they know its your will. The best example of real life delegates I can come up with is some kind of tv competition where the loser has to choose a forfeit - each forfeit is written on a piece of card and each card is put in a blank envelope so the loser doesn't know what they're chooing when they choose. Not sure it helps though.
jon.skeet (448) [Avatar] Offline
#2
Re: 2.1 Delegates and wills
(Deleted my own reply.)

I replied here, but it wasn't really well thought out. I'll try to think a bit further and then post properly.

The gist is *likely* to be that I see your point, but I like the analogy anyway - I think it gives enough of the "instructions embodied in a value" implication, even if the "unnamed" part isn't preserved. I would certainly hesitate to start talking about named/unnamed behaviour shortly before introducing anonymous methods - that's bound to cause confusion!

Jon

Message was edited by:
jon.skeet
Jon Jagger (11) [Avatar] Offline
#3
Re: 2.1 Delegates and wills
> I think I see your point, but I disagree with it. I
> think the main point about a delegate is the
> separation, largely in time, of the definition of the
> behaviour from its execution:

But that's no different from regular methods. I define a method and later on I may choose to call it. Writing a will is writing a method. Executing the will is executing the method. No delegate involved.

Hey! I got your reply before you edited it. Concurrency! FWIW I don't like the analogy/example. I think it serves only to confuse. I think the first para is spot on. I'd just drop the second para.

Message was edited by:
Jon Jagger
mgravell (64) [Avatar] Offline
#4
Re: 2.1 Delegates and wills
Just my tuppence... defining a (compile-time) method seems (in this analagy) comparable to simply listing the many, many things that it would be theoretically possible to do post-mortem [GiveAllToCharity(), UseToFeedCat(), BuryWealthInPyramid()]. No context, and no execution.

The will (delegate) instance defines a specific choice (or list of choices [multicast]) from that set of possibilities. Writing a will, then (to me at least) seems a pretty good match for declaring a delegate to a specific method.

Executing the method directly would be comparable to yourself, now, choosing to GiveAllToCharity(). Now... if only I could use a will to get "keep alive" behavior ;-p

[edited just to keep a trend]

Message was edited by:
Marc Gravell
Jon Jagger (11) [Avatar] Offline
#5
Re: 2.1 Delegates and wills
I think I see where my confusion is arising from. I was thinking of the will as a single method and the instructions in the will as the statements inside that method. That doesn't work. But if you think of each instruction in the will as a method call in its own right then it works fine. So with some minor tweaks it works nicely. Why not just change the 2nd sentence of the 2nd para to "It is a set of instructions (eg PayDebts, RemainderToMyCat). And the last sentence of the 2nd para to end "as a set of instructions, each one to be executed at the right time (eg PayDebts(), RemainderToMyCat())". You might also change the word set to sequence (twice).
jon.skeet (448) [Avatar] Offline
#6
Re: 2.1 Delegates and wills
Well, I think it already still works with the will representing a single-action delegate. It's still a case of embodying some action in a value (the will) which can be passed around instead of executed immediately - but I agree it contains *more* of an analogy if we make the will multicast.

In my manuscript, I've not gone with paying the milkman in case it doesn't translate well to the US, and I don't think it's worth including the list in the C# side, but here's what I've got for the whole of the second paragraph:

<quote>
If that’s just a lot of gobbledygook to you, maybe an example will help. It’s slightly morbid, but it does capture what delegates are all about. Consider your will – that is, your last will and testament. It is a set of instructions – “pay the bills, make a donation to charity, leave the rest of my estate to the cat” for instance. You write it before your death, and leave it in an appropriately safe place. After your death, your attorney will (you hope!) act on those instructions. A delegate in C# acts like your will does in the real world – as a sequence of actions to be executed at the right time.
</quote>

Does that seem okay to everyone?

Jon
peter.ritchie (7) [Avatar] Offline
#7
Re: 2.1 Delegates and wills
I think the will and testament analogy reasonably gets the point across that the person whose estate the will applies to isn't the person performing the actions. So, given the audience, it's a reasonable analogy. It's the legal writing style of the will that makes it unambiguously actionable. It's that writing style that I would view as the delegate type and the actual will the method a delegate instance would reference.

I think the analogy is a little misleading, mind you; is the person who wrote the will the programmer or the class/object? The will seems more like an object, leaving the person the programmer and the executor just an instantiation of another class that knows how to use the will object that was instantiated by another object. I agree with Jon Jagger, that sounds like just a method, not a delegate. A delegate is executed by code other than the class from which class/object the delegate references; but that class/object must still be "alive" (still exist in the case of a delegate to a class method and not be garbage collected in the case of a delegate to an instance method) or "be there" in order for that delegate to call that method--as alluded to in the 2nd-last paragraph of 2.1.1. This leaves the deceased neither the delegate type nor part of the delegate instance. The fact that the executor is delegated the task of administering the will is important to the analogy.

I don't know about the UK; but here in Canada the executor of a will doesn't have to be the person's attorney, or a solicitor at all. You still have milkmen in the UK?
jon.skeet (448) [Avatar] Offline
#8
Re: 2.1 Delegates and wills
This is the trouble with analogies - they try to make a broad point, but tend to fall apart when analysed too far. My gut feeling is that it gives the right overall *feeling*.

Slight pedantic defence on the garbage collecting bit: the estate of the person is still available, even though the person is dead. It's the estate that is being acted on, so the person can be garbage collected - the estate would be the target of the delegate, effectively. It's taking it all a bit too far though smilie

No idea about the legal position of needing an attorney etc, but I don't think it's important in this case.
peter.ritchie (7) [Avatar] Offline
#9
Re: 2.1 Delegates and wills
Yeah, I believe it gives the overall feeling. It depends on how nit-picky you expect your audience to be. I can imagine the feedback about Raymond Chen's book...

If that analogy confuses the reader so much that the rest of the chapter on delegates is made unclear, they probably shouldn't be reading your book. There may be better analogies; but I don't know if it's worth changing what you have. I'm only finishing up Ch 2; so I don't know if you've continued use of the analogy throughout the other chapters...
jon.skeet (448) [Avatar] Offline
#10
Re: 2.1 Delegates and wills
Nope, the analogy dies a death at the end of the chapter, and doesn't have any legacy smilie

Can't say I've read Raymond Chen's book... any good?
richard.fine (2) [Avatar] Offline
#11
Re: 2.1 Delegates and wills
I've just encountered this analogy on my readthrough and I found it uncomfortable enough that it sent me here to talk about it, at least.

The key properties of delegates are:
* They encapsulate some behaviour (a method call)
* They allow this behaviour to be executed at any time after it has been packaged, possibly multiple times
* They guarantee that the behaviour conforms to certain properties (i.e. that it matches a particular method signature)

My best attempt at an analogy is that of a restaurant with an infinite menu.

After looking through the infinitely long menu for a while, I place an order with one of the waiters, and he writes it down on his pad, and gives me a copy so that I can easily place the order again next time I visit, instead of having to try and find it in the menu again. He goes and clips it to the rack in the kitchen. Unfortunately, the chefs don't have the greatest work ethic, so there's no guarantee they'll ever get around to looking at my order - but if I'm lucky, some time later, one of the chefs comes to get the order from the rack. It has to be the right chef, of course, because apple pie can only be dealt with by the pastry chef, while Irish stew can only be made by the saucier, and so on. The chef reads the order, and looks up the recipe for the dish that it names - there's no point trying to learn the recipes for everything on the infinite menu, after all - and follows whatever it says to create my meal.
jon.skeet (448) [Avatar] Offline
#12
Re: 2.1 Delegates and wills
At the moment I have to say I prefer my analogy (which I suspect is to be expected) but I'll certainly give it some more thought.

Jon