Re: Dynamic Loading & Meta Programming

[Michael van Acken <acken@vanacken.do.uunet.de>]

> From: hartmut Goebel <hartmut@oberon.noris.de>
> Date: 	Sun, 18 Apr 1999 12:48:40 +0100
> 
> Michael van Acken (acken@vanacken.do.uunet.de) schrieb:
> 
>  >The Oberon-style of dynamic loading only provides dynamic access to a
>  >single kind of resource: parameterless procedures that are exported by
>  >the loaded module.
> 
> This is not fully correct, since dynamic loading and access to resources are
> seperate issues!
> 
> In the Oberon System(s) dynamic loading is used for a couple of purposes, eg.
> for the "commands" you mentioned. Further important usage is for loading
> "elements" (dynamic content for texts).

This is probably implemented through the `Types' module, isn't it?

>  >To get the full range of meta-programming it makes sense to slurp the
>  >symbol file into the program during run-time.  This way the whole
> 
> Sorry, I have to disagree here: for "the full rang of meta-programming" one
> does not only need information about the interface, but much more important
> information about _all_ procedures and variables.
> 
>  >This would even work with oo2c.
> 
> As we discussed earlier, implementing "Ref" is not possible with oo2c :-(
> 
>  >After array descriptors have been added to the run-time environment,
>  >all program data (excluding the procedure stack) can be accessed
>   ^^^^^^^^^^^
>  >through a `Ref'-like library module.
> 
> In no way corect, sorry (accourting to what you wrote above). You'll still
> miss global, non-exported vars.

How does this work together with information hiding and encapsulation?
If a module's private data and procedures are made available for
arbitrary clients, how can the module ensure that its own data is
correct?  How can a module guarantee that the invariants it imposes on
its own state are not invalidated?

Making everything public through a `Ref'-like mechanism defeats the
purpose of clearly defined interfaces as a means of program
abstraction.

> NB: trying to implement "Ref" without full access to local variables, too, is
> simply worthless: you'll loose a big part of it's functionality.

I remember that you said something like this before.  I know about two
uses of full access to the run-time stack: run-time debugging and
implementing exceptions.  The disadvantage of this kind of access
within OOC (read: _any_ OOC based compiler) would be a severe
performance impact.  Slowing down programs by a noticable factor just
to peek at a procedure's local variables does not make any sense at
all IMO.

-- mva