[DGD]DGD extension interface, some thoughts

[E. Harte]

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?

>    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...

  int mark_special(object obj, string type);
  string query_special(object obj);

..or however you have pictured this in the C interface. :-)

> The management of an object's external state is entirely the
> responsibility of the module writer.  However, special objects
> have some additional features:
> 
> Each special object has an extra hidden variable which is not
> accessible from LPC code.  A kfun can store typical LPC data in this
> variable, so that the "external" state of an object does not need to
> be separately allocated but can be swapped out with the object, or
> even stored with the object in a state dump.  Furthermore, changes to
> this value will automatically be undone by atomic code when required,
> so that the special object can conform to the atomic state.

To point out the obvious, this special variable is not bound to
sector-size or other arbitrary limits, but can contain mappings, arrays,
strings, etc.

Erwin.
-- 
Erwin Harte  -  Forever September, 2583 and counting  -  harte at xs4all.nl
[ 10:53pm  up 49 days,  3:10, 14 users,  load average: 0.02, 0.03, 0.00 ]


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