[Oberon] Protocols (interfaces) in Oberon-2
Charles Perkins
chuck at kuracali.com
Sun Oct 25 18:29:14 CET 2020
Andreas and Jörg and Lucas,
Thanks for considering how Interfaces can be expressed in Oberon, either
natively or through an extension of the language.
Andreas, in your scheme can you create separate protocols, for example
"Jsonify" with the method ToJSON and a different protocol "Persistify" with
the methods "Store" and "Load", and have other records implement one or the
other or neither or both?
Maybe you can, I have to study your proposal more.
I'm not actually talking about multiple inheritance here... just
composition of behavior.
Regards,
Chuck
On Sun, Oct 25, 2020 at 9:56 AM Andreas Pirklbauer <
andreas_pirklbauer at yahoo.com> wrote:
> > I have the above code successfully parsing in a fork of Andreas's
> > Extended Oberon compiler. I don't have the method table generation
> code
> > working yet. It turns out that the Run-time needs to have symbolic
> type
> > information available, which could be simply loading the smb file
> alongside
> > the rsc file for code that uses interfaces, or it could involve
> embedding a
> > hash of the name and parameters of the type-bound procedure in
> another
> > section of the rsc file. I haven't decided yet.
>
> Dear Chuck,
>
> In the proposal put forward earlier in this thread (see example below),
> almost no extra code is necessary in the compiler or the runtime, because:
>
> 1. A protocol definition *is* in fact just a regular record definition -
> the
> only difference being that there now is an additional “executable” flag
> that indicates that its type-bound procedures cannot be executed.
>
> 2. A protocol implementation *is* is fact just a regular type extension
> (of a protocol definition - which this is why the same syntax has been
> chosen), where this flag is simply changed such that its type-bound
> procedures *can* now be executed.
>
> That’s all there is to it. Well almost. One also needs to slightly modify
> the type checking rules of the compiler such that two protocol
> implementations (=type extensions) of the same protocol definition
> (=the base type) are in fact assignment-compatible (unlike two
> “regular” record extensions of the same base type which are not).
>
> And of course the "non-executable” flag must be correctly propagated
> across symbol and object files as well.
>
> -ap
>
>
> MODULE TextProtocol; (*protocol definition*)
> TYPE Text* = POINTER TO TextDesc;
> TextDesc* = RECORD data*: (*text data*) END ;
> PROCEDURE (t: Text) Insert* (string: ARRAY OF CHAR; pos: LONGINT);
> PROCEDURE (t: Text) Delete* (from, to: LONGINT);
> PROCEDURE (t: Text) Length* (): LONGINT;
> END TextProtocol;
>
> MODULE Text1; (*one implementation of the Text protocol*)
> IMPORT TextProtocol;
> TYPE Text* = POINTER TO TextDesc;
> TextDesc* = RECORD (TextProtocol.TextDesc) END ; (*this means:
> “implements TextProtocol.TextDesc"*)
>
> PROCEDURE (t: Text) Insert* (string: ARRAY OF CHAR; pos: LONGINT);
> BEGIN (*implementation of Insert*)
> END Insert;
>
> PROCEDURE (t: Text) Delete* (from, to: LONGINT);
> BEGIN (*implementation of Delete*)
> END Delete;
>
> PROCEDURE (t: Text) Length* (): LONGINT;
> BEGIN (*implementation of Length*)
> END Insert;
> END Text1;
>
>
> MODULE Text2; (*another implementation of the Text protocol*)
> IMPORT TextProtocol;
> TYPE Text* = POINTER TO TextDesc;
> TextDesc* = RECORD (TextProtocol.TextDesc) END ; (*this means:
> “implements TextProtocol.TextDesc"*)
>
> PROCEDURE (t: Text) Insert* (string: ARRAY OF CHAR; pos: LONGINT);
> BEGIN (*implementation of Insert*)
> END Insert;
>
> PROCEDURE (t: Text) Delete* (from, to: LONGINT);
> BEGIN (*implementation of Delete*)
> END Delete;
>
> PROCEDURE (t: Text) Length* (): LONGINT;
> BEGIN (*implementation of Length*)
> END Insert;
> END Text2;
>
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20201025/bce7619a/attachment.html>
More information about the Oberon
mailing list