[DGD] 1.2.102
Par Winzell
zell at skotos.net
Thu Apr 7 21:24:01 CEST 2005
Felix A. Croes wrote:
> The list of undefined functions is added so that a mudlib can forbid
> active use of such objects, and can generate reasonable errormessages.
> From a Java point of view, an object with only prototypes would be an
> interface.
>
> The "list" is actually a mapping. When object obj has no undefined
> functions, status(obj)[O_UNDEFINED] is nil. Otherwise, it is a
> mapping of the following format:
>
> ([ program_name : ({ func1, func2, ... )}, ... ])
The mudlib support to provide 'proper' support for abstract functions is
not entirely trivial, and as I just finished (with Dworkin helping me
work through the issues) an implementation for the SkotOS 2.0 codebase,
I thought I'd briefly summarize my findings. This is probably only one
of many possible implementations, especially since I assume the use of
the kernel library.
- You will want to mask compile_object() in the System level auto
object, if you are not already doing so. You need two separate systems
to check for two separate kinds of unimplemented functions:
+ For concrete objects, use status(obj)[O_DEFINED] and simply report
any unimplemented functions that are either declared in the compiled
program or inherited normally. A concrete object by definition should
not have any undefined functions.
+ The status() function does not report prototypes that were
privately inherited. It is quite common to privately inherit a program
that declares prototypes it expects its inheritor to implement. To catch
cases where the inheritor fails to implement them:
* Allocate space for a new TLS slot.
* In your objectd, add code to forbid_inherit(), compile() and
compile_lib() that keeps track of the undefined functions of each
privately inherited program.
* In your masked compile_object(), initialize the TLS slot with
whatever data you need for the previous step. Remember that compilation
of one program may trigger compilation of many other programs when
creators are run.
* At the end of compile_object(), go through the datastructure
(which is likely quite large) you collected in the objectd. For each
compiled program:
$ Figure the master list of privately inherited undefined functions.
$ From this master list, REMOVE any undefined functions that
were NON-privately inherited. If I inherit a prototype both privately
and non-privately, the private inheritance is irrelevant.
$ From the rest of the master list, REMOVE any function that is
actually defined by the compiled program. To do this, you will need to
employ function_object(), but:
= function_object() from the 'outside' fails to detect static
methods and so you need to create some kind of function_exists() relay
in the auto object that performs function_object() on itself
= function_object() cannot be run on pure programs, because
the kernel library forbids us from getting an object pointer to such a
program; thus we create a temporary object that does very little but
inherit the program we actually want to test, and then call
function_exists() on this program.
Phew. OK, that sounded complicated. I guess it was. But it works! LPC
has matured even further!
Zell
More information about the DGD
mailing list