[Oberon] Exporting pointers
joerg.straube at iaeth.ch
Thu Dec 21 11:56:28 CET 2017
An object has the field "expo" to tell the compiler whether an object
(const, type, var) is exported or not.
For types, only RECORDs can be extended in other modules, so the variable
"exno" identifies the exported base RECORD. For other types this numbering
is not needed.
From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of Srinivas
Sent: Thursday, December 21, 2017 10:23 AM
To: chris at cfbsoftware.com; ETH Oberon and related systems
<oberon at lists.inf.ethz.ch>
Subject: Re: [Oberon] Exporting pointers
You are correct.
Many thanks for your valuable input.
Now I wonder, what is the true purpose behind 'exno'?
With thanks and best regards,
On 12/21/2017 12:50 PM, Chris Burrows wrote:
>> -----Original Message-----
>> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of
>> Srinivas Nayak
>> Sent: Thursday, 21 December 2017 4:21 PM
>> To: ETH Oberon and related systems
>> Subject: [Oberon] Exporting pointers
>> Dear All,
>> Looks like the current RISC-5 Oberon7 compiler allows only RECORDs to
>> be exported, although language says a pointer type can also be
>> exported. I see export number only incremented in case of RECORD type
>> in ORP.Mod.
>> Kindly let me know if I am mistaken.
> There must be some misunderstanding. Look at the Project Oberon source
> for examples. You shouldn't have to look very far - I counted about a
> of dozen exported pointer types in fifteen different modules. There are
> in Graphics.Mod alone.
> At the risk of stating the obvious, any other type (not just RECORDs or
> POINTERs TO RECORDs), can be exported as well.
> Chris Burrows
> CFB Software
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
More information about the Oberon