[DGD]DGD extension interface, some thoughts
Felix A. Croes
felix at dworkin.nl
Tue Sep 26 18:14:18 CEST 2000
Ludger Merkens <balduin at uni-paderborn.de> wrote:
> > Whenever an LPC-level function is called which is defined in the
> > program of a special object, the call may be redirected to a C-level
> > function, which will be called using the normal kfun interface. It
> > will not be possible to call LPC functions from there.
> >
>
> Is there a way to remove this restriction? Assume you wan't to write an
> XML parsing toolkit, e.g. with sax interface, you'd really like to use
> callbacks to lpc to handle the tags. Another problem I see would occur if
> somebody wanted to change the netpackage into a module, since this also
> calls lpc callback functions. Especially interesting would be to let the
> module run in its own thread and call the cb-functions from there on
> demand.
I added this restriction because doing this right would be rather
complex, and reaches deep into the guts of DGD. Consider:
The function that is being masked by a C-level function can be
private, or itself masked by another function in the relevant
object. All that matters is that the object which defines the
function is marked as special; it may be inherited, and so on.
The bindings for function calls are normally determined at
compile time. For an LPC call from a C function, it would
have to be determined at runtime. Is a call to another
private function in the same object possible? What is that
function has been masked? Is it at all reasonable that this
function should be able to call a static function in a different
object, as ordinary driver callbacks can do -- which would work
around the ordinary object protection & abstraction model?
I may decide to allow the standard callbacks, which can also be
done from kfuns, but even that seems wrong to me. Different rules
should apply to functions that are actually part of an object,
and to kfuns.
Of course, it is still possible to do the networking package as
a module even with this restriction, because modules can define
their own kfuns.
Regards,
Dworkin
List config page: http://list.imaginary.com/mailman/listinfo/dgd
More information about the DGD
mailing list