[Oberon] Protocols (interfaces) in Oberon-2

[Joerg]

Stewart

An interface in a framework (like COM defined by Microsoft) and a language construct like INTERFACE have no direct relationship.

If a framework defines an „interface“ (API), it does not necessarily mean the language needs to offer a language construct INTERFACE.

I could imagine the interface of a framework defines things like
- mandatory datastructures and hierarchies,
- the presentation layer (=memory layout) of the data structure (first field is this, second field is this...)
- mandatory methods/procedures with defined semantics to be implemented on this datastructure
- If you use COM on Windows, the calls have to follow the Windows calling rules (parameters are passed in registers not via stack)

As long the language and the compiler can generate the needed rules defined by the framework, we‘re fine off.

At the moment - without digging into the details - I don‘t see something in the COM framework that couldn‘t be done in Oberon. That said, I agree that some syntax is cumbersome or verbose and could be streamlined to reach the same goal.
- If the framework for example differentiates 16 bit and 32 bit integers, we would have to do something as the Oberon-07 language only supports one INTEGER type and NW’s compiler maps it to 32 bit.
- If the framework assumes finalizers (Release method), we can do this in Oberon-07 but the programmer needs more discipline as this is not built-in into the language and has to be programmed explicitely. I agree that a compiler generating these Release calls automatically can help getting rid of memory leaks. With such an adaption, Oberon is no generic programming language any more but very specifically finetuned for COM programming.
- If the calling rules request fine grained control on register allocation, and the compiler does it differently we have to do something

br
Jörg

> Am 28.10.2020 um 01:12 schrieb Stewart Greenhill <stewart.greenhill at gmail.com>:
> 
> 
> I'm not sure if I caught all of this interesting discussion, but here are a couple of points.
> 
> Interfaces are of course an important mechanism for component software frameworks, such as Microsoft's COM (Component Object Model). COM defines a language-independent binary standard for communication between objects, whether they are in the same process, in different processes on the same machine, or on different machines.
> 
> https://docs.microsoft.com/en-us/windows/win32/com/com-objects-and-interfaces
> 
> During the 1990s, Oberon Microsystems implemented an extension of the Component Pascal compiler in Blackbox which was called "Direct TO COM" (or "DTC"). This allowed COM components to be written in Component Pascal, and for such components to interact with objects written in any other language.
> 
> https://web.archive.org/web/20040618025116/http://www.oberon.ch/prod/DTC/index.html
> 
> I can't remember all the details, but one of the important technical issues is that COM interfaces (and therefore the generated Oberon objects) use C++ VTBL object representation. That is, the first element of every object is a pointer to a table of its virtual methods, which is different to the usual layout for Oberon-2 records.
> 
> COM is based on a fairly simple but powerful idea: Every object must implement the interface "IUnknown", and every interface must extend IUnknown. The method IUnknown:QueryInterface allows the client to retrieve other interfaces of the object, which in COM are named using GUIDs ("globally unique identifier). This mechanism allows an object to implement one or more of its own interfaces, or indeed for it to delegate its own interfaces to other objects (eg. via aggregation)
> 
> PROCEDURE (this: IUnknown) QueryInterface (IN [iid] iid: GUID; OUT [new] int: IUnknown): RESULT;
> 
> To implement a single interface, you define an object that extends the interface type. To implement multiple interfaces, you would need to define a separate object for each additional interface, which would hold a pointer to the main object and forward any method calls from the interface object to the main object. This could involve some work, but would be fairly simple and could potentially be automated.
> 
> A slightly different implementation is described in "Fine-grained integration of Oberon into Windows using pluggable objects" by Emil Zeller. This includes a quite detailed description of how he integrated Oberon-2 objects into Microsoft's OLE2 compound document model. This includes interfaces for object persistence, display, and interaction. There is also an interface "IDispatch" which allows properties and methods of objects to be enumerated at run-time, so that components can be integrated into scripting environments or visual editors. 
> 
> https://www.research-collection.ethz.ch/bitstream/handle/20.500.11850/72691/eth-26257-02.pdf
> 
> I'm not sure much of this is directly useful, but its definitely worth understanding what COM is and how it works. The underlying ideas are fairly simple, and could easily be emulated in a small-scale project.
> 
> Cheers,
>   Stewart
> 
> --
> 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/20201028/6f0c5dd6/attachment.html>