[Oberon] Protocols (interfaces) in Oberon-2

[Charles Perkins]

Right. It is helpful to be able to compose behaviors (interfaces) in a data
type (e.g. record with type-bound procedures) implementing more than one
interface without "inheriting" the actual code but instead executing
procedures written for that specific data type against those interface type
signatures.

On Sun, Oct 25, 2020 at 10:58 AM Luca Boasso <luke.boasso at gmail.com> wrote:

> Probably multiple inheritance was not the right name. It is essentially
> type extensibility with the ability to extends multiple types at once. This
> is safe and does not have the the downsides of multiple implementation
> inheritance, where you share code.
>
> On Sun, Oct 25, 2020, 12:29 Charles Perkins <chuck at kuracali.com> wrote:
>
>> 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
>>>
>> --
>> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
>> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>>
> --
> 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/26566752/attachment.html>