NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/lang/cplus/17883

Internet Message Format | 1992-12-12 | 5.2 KB

Path: sparky!uunet!spool.mu.edu!wupost!cs.utexas.edu!tamsun.tamu.edu!tamsun.tamu.edu!news
From: [e-mail] (The Man Behind The Curtain)
Newsgroups: comp.lang.c++
Subject: Re: Criticisms Wanted:Callbacks&Runtime methods
Date: 12 Dec 1992 22:36:46 -0600
Organization: Texas A&M University
Lines: 103
Sender: [e-mail]
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
NNTP-Posting-Host: tamsun.tamu.edu
Keywords: callbacks C++ Runtime methods

Thus spake [e-mail] (John MAX Skaller):
>In article <[e-mail]> [e-mail] (The Man Behind The Curtain) writes:
>>
>> [..runtime determination of methods..]
>>
>>But these capabilities are useful, and even necessary when you try
>>to model the real world.  For instance, might double click a key, and
>>then select from the screen any object to try to unlock with the key,
>>be it a bear, bush, or door.  These classes are mostly unrelated, but
>>in order to be able even attempt the operation, the base class of such
>>objects must at least have method for unlocking.  If objects can
>>interact in a wide variety of ways (a large number of verbs), then
>>the base class would contain an unweildy number of virtual functions.
>
>    So put in all those methods! It is not expensive per object,
>only per class. I know exactly what you are talking about, having
>spent some months preparing a quote for a D&D game. There is
>a simple set of properties, but the objects all have different
>combinations of them. The interactions of different weapons,
>wielded by different characters against different classes of
>monsters is complex, and it cannot be easily generalised.

Yes, that's my problem.  But I would like to try to avoid the
class complexity which you mention, by encoding into each class
only those methods which belong.  You are right about not being
easily generalized -- one ends up trying to impliment a kind
of 'naive physics.'

>    One approach is to emulate the dynamism that C++ lacks.
>For while C++ is essentially static, it provides the low level
>tools to implement much more powerful systems.
That's what I'm trying to do.

>    For example, you can suuply to each object a linked
>list of attributes: asking if an object has the attribute
>'can be unlocked' is then simple to implement (scan the list
>for the attribute name 'unlockable'.

But the overhead for such scanning would be prohibitive.  True,
one could impliment it as a set (something I played with for
a while).  But I didn't like the additional memory requirements
then, which simply duplicated information which could possibly
be extracted in code.  I may decide that the space overhead is
trivial.

>    The static alternative is to make all objects
>unlockable, except some have probability of sucess 0 with
>any key.
That's one approach.  But for 'cleanliness' I'd like to have that
zero probability implicit.

>    The third approach is to use Smalltalk :-)

That's a possibility.  But given the choice of using Smalltalk and
implimenting these easily, but then trying to coax it into acceptable
performance, and using C++ and painfully implimenting similar
dynamics in the classes which need it and taking performance hits
only when necessary, I think I'll pick C++.

>You will note that your problem cannot be solved 'properly' no matter
>what you do, since it requires nonexistant multimethods, that is, the effect
>of putting some key in some door cannot in general be computed
>with virtual functions: it depends on the exact type of the two objects.
>The only way to do it in general is with a very large lookup table.
>To avoid this, simplifiying assumptions are required: some general code
>and some special cases.

Actually, I don't believe that this is true.  Vaguely, I recall a paper
presented at OOPSLA '91 which described Multimethods in a Static-
Typing System.  Theoretically at least, it is possible, but I haven't
had much success in implimenting it--apparently I would have to
go down to the compiler level.

>    For example, all swords work the same way, they just have
>different probabilities of hitting, penetration and damage.
>Multiplication and addition of numbers is the most general
>mechanism I can think of, along with a few special cases.
>
>    (Whenever a Dragon Slayer is used on a Dragon, triple
>damage results and the dragon loses er fire for two rounds,
>provided the damage was to the head .... )

While I can currently impliment the simple sword, and even the
DragonSlayer (with some cooperation between the sword & the dragon--
both must know of their own existance, the sword to triple its
damage and the dragon to inhibit its fire) what I can't impliment
is a dynamic addition of methods.  For instance, if one disguises
one's self as a guard, the method isGuard() would be added to
the class, but the way that I do it now, this is only possible
if I verb(isGuard); to begin with, and implimented ..::isGuard(void) {
return 0; }.  In order to be able to do such things, I would need
to go with the set idea that you expressed earlier.

> JOHN (MAX) SKALLER

Thank you for your very thoughtful and informative post!


--
Till next time,                \o/   \o/
                                V \o/ V     email:[e-mail]
<>  Sam  Inala  <>                 V