[MUD-Dev] Spoofs

Brian Hook bwh at wksoftware.com
Wed Sep 26 00:29:52 CEST 2001


I'm not sure what spoofs are trying to accomplish, even after
reading the original post on them.  They sound very similar to
Objective-C delegates or even the standard "letter/envelope" idiom
in C++ (a la Coplien).  Anyone know the relevant differences between
a spoof and a delegate?

On a slightly off-topic note, I finally got around to reading
"Design Patterns".  While I think much of it is overrated (at least
for people that have independently discovered the patterns =) ),
there were parts that made me go "Whoa, that's a perfect a
description for something I've intuitively known for a long time".

The classic illustration is they inadvertently illustrate why C++ is
basically broken -- it ties the interface and implementation to each
other tightly.  So when B inherits from A, you're never sure (from
the outside) if it's inheriting the interface (for polymorphism) or
the implementation (for specialization) or both.

They go on to make an even more interesting assertion: extension by
aggregation is generally preferable to extension by inheritance for
the above reason.  They almost seem to actively discourage
subclassing.  I have to admit that I'm fairly guilty of using "is-a"
vs. "has-a" a lot more than I should, but I'm slowly getting over
it.  Hell, I'm using callbacks for a lot of stuff now instead of
polymorphism because, in the end, it's actually quite a bit cleaner
than subclassing everything just to minorly extend its behaviour.

Obj-C somewhat mirrors this philosophy (as a result of being an
outgrowth of Smalltalk, which I'm just now coming around to
realizing was WAY ahead of its time) via its delegate idiom and with
its formal and informal protocol capabilities.  I just really dig on
being able to ask any arbitrary object if it responds to a
particular message without having to know its type a priori.

Brian

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev



More information about the mud-dev-archive mailing list