[Oberon] SystemV- Heap + Module Space

Jörg joerg.straube at iaeth.ch
Sun Jan 6 13:34:25 CET 2019


I fully support named constants.
Jörg


Am 06.01.2019 um 11:27 schrieb Chris Burrows <chris at cfbsoftware.com>:

>> -----Original Message-----
>> From: Jörg [mailto:joerg.straube at iaeth.ch]
>> Sent: Sunday, 6 January 2019 5:32 PM
>> To: chris at cfbsoftware.com; ETH Oberon and related systems
>> Subject: Re: [Oberon] SystemV- Heap + Module Space
>> 
>> Yes and no.
>> From an encapsulation point of view you're right.
> 
> That is how it is done in ETH Oberon for Windows. There are local named (camelCapped) CONSTs for each error code defined in Win32.Modules.Mod: 
> 
> CONST
>    done = 0;
>    fileNotFound = 1;
>    invalidObjFile = 2;
>    corruptedObjFile = 4;
>    cmdNotFound = 5;
>    moduleNotFound = 6;
>    notEnoughSpace = 7;
>    refCntNotZero = 8;
>    cyclicImport = 9;
>    incompImport = 16;
> 
> Note the additional codes; 3 is a mystery value this time ;-)
> 
> Error string mapping to these codes is performed in the same module by PROCEDURE ErrMsg(res: INTEGER). Interestingly this doesn't just store the error message in a string, it actually calls a Kernel32 procedure to output the string. However, the output procedure is a variable declared as OutputStringProc* = PROCEDURE (VAR str: ARRAY OF CHAR); presumably to allow runtime control of how the output of those strings is to be handled.
> 
>> Let's assume you want to offer the error messages in different
>> languages. Then it's questionable if you want to have the text
>> translations in the Inner Core.
>> TextFrames (with the translation strings) is in the Outer Core and
>> can be exchanged more easily.
>> 
> 
> While that is true - I consider that to be a red herring in the context of named vs. anonymous constants. Internationalisation isn't something that can be readily added on to an existing software system as an afterthought. It has to be designed in from day one - not just the software, but also all documentation, help files, access to technical support  etc. etc.
> 
> Chris.
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon



More information about the Oberon mailing list