[Oberon] SystemV- Heap + Module Space

[Jörg]

Chris

Yes and no.
>From an encapsulation point of view you're right.
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.

br
Jörg


Am 06.01.19, 00:03 schrieb "Oberon im Auftrag von Chris Burrows" <oberon-bounces at lists.inf.ethz.ch im Auftrag von chris at cfbsoftware.com>:

    > -----Original Message-----
    > From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of
    > Andreas Pirklbauer
    > Sent: Sunday, 6 January 2019 3:34 AM
    > To: ETH Oberon and related systems
    > Subject: [Oberon] SystemV- Heap + Module Space
    > 
    >    > Oberon.Activate(): even better with a CASE??
    > 
    > Ok, so.. for those who use an Oberon compiler, which implements the
    > numeric CASE statement  ??
    > 
    >   PROCEDURE Activate*(F: Viewers.Frame; T: Texts.Text; pos: LONGINT);
    > (*command*)
    
    If possible, the logic that maps error codes onto error messages should be located in the module where the error codes are defined. Then the client call could be just:
    
          SetPar(F, T, pos + S.len); Call(S.s, Mname, Cname, res);      
          IF (res # Modules.noerr) & (Log # NIL) THEN Texts.WriteString(W, "Call error: ");
            Modules.GetErrorMsg(res, msg);
            Texts.WriteString(msg);
            Texts.WriteLn(W); Texts.Append(Log, W.buf)
          END
    
    The CASE statement is contained in Modules.GetErrorMsg and the non-standard ELSE in the CASE statement is redundant.
    
    If all error codes have the same end result in the clients, then you only need to export Modules.noerr.
    
    Chris.
    
    
    
    --
    Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
    https://lists.inf.ethz.ch/mailman/listinfo/oberon