[DGD] Re: Definition order blues

[Felix A. Croes]

Shentino <shentino at gmail.com> wrote:

> Specifically, I'm having a fit over this:
>
> If I move function B after function A, then function A won't call my
> version of B, but an inherited version.  This, in spite of the fact
> that both A and B are forward declared before either definition.
>
> What gives?

DGD is a re-implementation if LPmud, and intended to be compatible
with at least LPmud 2.4.5.  One of the things it inherited from that
predecessor is people who make muds, and one of the things those
people do is create include files which contain prototype declarations.
This is a completely pointless emulation of a C programming necessity,
but one which is harmless in LPmud.

DGD originally behaved like you expected, and a prototype or forward
declaration would introduce a new function.  Unfortunately, since
programmers would include header files with prototypes for functions
that were already inherited, this resulted in non-working code.  For
the sake of backward compatibility with LPmud, I had to make a change
so that a prototype declaration which exactly matches an inherited
function is ignored.

To further complicate the issue, a call from A to B will normally
go to the new B anyway (and to any newer B declared in an object
that inherits the current one) unless B is a static function in
the auto object.  For a number of reasons, including some security-
related ones, calls to static functions in the auto object behave
like calls to kfuns, with an implicit `::'.

I've never much liked the change I had to make to the way prototypes
work, so I propose to make the following new change to DGD: a prototype
can never match a static function in the auto object and will always
introduce a new function.  This breaks backward compatibility, but
only in a very minor way, and it will not affect most of those who
use C-style header files.

Would that solve your problem?

Regards,
Dworkin