[MUD-Dev] Re: DevMUD: Inheritable modules

Chris Gray cg at ami-cg.GraySage.Edmonton.AB.CA
Sat Oct 31 12:05:19 New Zealand Daylight Time 1998

[James Wilson:]

 >/* God bless those macros */
 >#define declare(ret,name,args) ret (*name) args
 >#define resolve(ret,name,args) name = _lookup (#ret, #name, #args)

I'm not a big fan of C macros like this, since they can be hard to read
and debug. And, it took me a minute or so to see just what was happening
here. However, these do work out pretty good!

[description snipped]


Again, I'll just say that I mostly agree.

I was thinking for a while about ways to ensure at runtime that the
functions match up properly in terms of prototypes, but I don't think
it can be done. If we require that each module include type-information
about the interfaces it implements/uses, we can check that information
at binding time, but we are then just relying on the the correctness
of that information, rather than on the word of the programmer of the
module. Since both can be wrong, either accidentally or deliberately,
I'd say we shouldn't bother with trying to do any checking. Just assume
that if a module says it implements interface X, then assume that it
does so correctly, and go ahead and use it. I still think that for
each interface in the system, there should be available at run-time, the
definition of everything in that interface, so that run-time generated
code can use it. Since using it requires an implementation of the
interface, I suggest that all modules that implement an interface should
include, in their structures that say that they implement it, a full
specification of that interface.

C++ does this at link time via name mangling, and that sort of approach
has been suggested here. However, we don't have any nice automatic way
to generate those mangled names, so I suggest unmangled names with
extra info that describes the prototypes. That way, the extra info
doesn't have to fit within the definitions of identifiers for any
programming languages, and so can perhaps be easier to work with.

Don't design inefficiency in - it'll happen in the implementation. - me

Chris Gray     cg at ami-cg.GraySage.Edmonton.AB.CA

More information about the MUD-Dev mailing list