Re: Signature in Oberon/F

Bruno Essmann (bessmann@iiic.ethz.ch)
Sat, 15 Jun 1996 01:09:24 +0200

Hi Stan,

>There does not seem to be a precise definition of "signature" in
>the Oberon/F documentation. Nor does there seem to be an explanation
>of how the framework uses signatures to make implicit calls to
>exported procedures. Specifically, in MODULE Dialog the documentation
>states:
>
>TYPE NotifyProc = PROCEDURE (op, from, to: LONGINT)
>Control notification commands must have this signature.
>
>Then, in MODULE ObxDialog there is the procedure:
>
>PROCEDURE SelNotify* (op, from, to: LONGINT);
>
>which apparently has the required signature. What does it take for
>a procedure to have the right signature:
>(a) Must the formal parameters match in number and type exactly?
>(b) Must the formal parameters have the same names?
>(c) Must the procedure have some common substring in its name,
> e.g. "Notify" in the above example.
>(d) What are the Framework rules for determining when a procedure
> is called by the framework?

Signature as understood in the Oberon programming language means only (a),
I haven't tried if the Oberon/L compiler also checks if (b) matches since
I'm usually to lazy to give my own names so I used the copied ones, but if
the compiler doesn't explicitly check this (i.e. if it's the only Oberon
compiler that checks this) than I'd say no.

>For example, in ObxDialog what distinguishes the calling of
>
>PROCEDURE DisableNotify* (op, from, to: LONGINT);
>
>from the calling of
>
>PROCEDURE ElemsNotify* (op, from, to: LONGINT);

The calling of a procedure is defined - in this case - by the dialog form.
If you open the dialog as a normal document, select a button (or whatever)
and then choose 'properties' you'll get a dialog that lets you change the
notifiers/guards/etc. The framework then calls these procedures whenever
necessary, e.g. a guard procedure is called whenever Dialog.CheckGuards is
executed which in case will be executed whenever an element of the dialog
changes (e.g. by a notifier procedure which was called in response to a
mouse click). As matter of fact all the matters is that the framework will
make sure that the guards/notifiers are called when necessary so you don't
have to worry exactly when this will be... (Hope that doesn't sound to
confusing :).)

>This framework concept is really different from many environments
>I have used before and I wish the documentation were more detailed
>in its description of the calling mechanism.

Well, the best documentation you can get for a framework is its source (as
seen in smalltalk). Unfortunately OMI doesn't give away much of the sourcecode
but if you examine how the forms subsystem works then you'll learn very much
about the framework. So best forget about the docu and have a look at as many
sources as you can get :))

Hope this helps,
Bruno