[DGD]DGD extension interface, some thoughts

[Felix A. Croes]

"E. Harte" <harte at xs4all.nl> wrote:

> On Tue, 26 Sep 2000, Felix A. Croes wrote:
>
> [...]
> > At module initialization time, the following actions are possible:
> > 
> >  - add a kfun
> >    Add a kfun using a regularized interface, possibly replacing a
> >    builtin kfun.  At runtime, the kfun will be called using a
> >    simplified interface; conversion to and from this interface is
> >    the responsibility of DGD.
>
> I assume these kfuns will have the usual flexibility in return types,
> argument-types, as is now available by patching DGD sources?

Of course -- and I mean to simplify the interface to make it easier,
too.


> >    Normal kfuns are stateless.  However, a kfun may be defined that
> >    marks an existing object as "special", as explained below.
> [...]
> > Special objects in DGD have some additional meaning that is external to
> > the ordinary LPC environment.  Examples of such objects are user
> > objects, editor objects and parse_string objects.
> > 
> > A kfun may mark an object as special.  Thereafter, the object becomes
> > associated with some external state or context.  DGD recognizes only
> > one type of special object; differentiating between several types is
> > the responsibility of the module writer.  A special object cannot be
> > also a user, editor or parse_string object at the same time.
>
> How do you picture this 'differentiating'.  By checking the existance of a
> 'special' function, contents of a variable, or something completely
> different?  To help the various module maintainers it might be useful to
> at least provide a way to label the special object with a string value...

Each object has an "etabi" (external table index) field, which can be
used for fast lookup in an external table.  However, this may ultimately
be insufficient since the etabi field is not restored from the state
dump -- it is meant to be a quick link from object to external state in
a running driver, only, and it may be too costly to have an etabi field
of the required width in each and every object.

You could either use object->state hashtables, or store the type of the
state in the object's extra variable.

Regards,
Dworkin

List config page:  http://list.imaginary.com/mailman/listinfo/dgd