On Tue, 23 Nov 2004, Robert Klemme wrote:

>
> Hmmm,
>
> as the writing and reading instance is the same, what about writing a
> class that acts as a block proxy and that recreates the code after loading
> the way you described but with a single difference: the code is encryptet.

Yes, that would solve one of the problems.  I could keep the
key in the code on the previously given assumption that people
won't poke about in the code so much as in config files...

> Of course, with reasonable effort it's still easy to play foul - but at
> least you can make sure that noone changes serialized code accidentally or
> on purpose and then simply loads it.

and with suitable checksums I can make it a bit more difficult to
forge.
>
> Another thing in the direction of your mini-language could be this: you
> write a class that describes the callback relationship.  Callbacks
> typically just forward an event to somewhere (or you can enforce this
> rule).  Then the callbacks are generated from the connection information
> (source instance, source event, target instance, target method to invoke).

Yes, that would do it, though I couldn't see how to do that before.
Now I think [having gone AFK for coffee] that there might only be a
small number of callback procs I'm likely to need anyway, so I could
represent them as symbols, and never serialize procs at all.
>
> Just my 0.02EUR...

Thank you.
>
> Kind regards
>
>    robert
>
         Hugh