[Oberon] Serious type loophole in type case statements and a possible fix
Andreas Pirklbauer
andreas_pirklbauer at yahoo.com
Fri Oct 30 18:38:28 CET 2020
Jörg, see inline comments:
> Andreas
>
> > 1. Global case variables p in a case statement CASE p OF .. END
>
>Module initializers can not have a CASE. But this seems acceptable.
Module initializers can always call a procedure Init, where a local variable is
assigned to the global one, and the CASE statement uses only the local one.
>>
>> 2. Assignments *to* case variables p *within* the scope of a CASE statement
>
>If needed, declare a local variable and „mirror“ p. Seems an acceptable restriction.
I don’t see why one *should* be allowed to assign something *to* a case variable in
the first place. It breaks the whole idea of the type case statement, namely that
the type of the case variable remains *constant* among the statements of a particular
branch of the case statement. But yes, using a local variable is always possible.
>>
>> 3. Passing a pointer case variable p as a VAR parameter to a procedure P(p)
>
> I could imagine an example where you have a CASE in a loop and the procedure
> P returns an object with another type to be
> processed by the next iteration.
> Here the „trick“ with the local variable as mentioned above can help as well.
> Restriction for such >rare cases seems acceptable.
>
Seems like an edge case. Never seen! But yes, here too, local variables can be used.
> Jörg
All in all, the restrictions seem quite acceptable. The reason for *keeping* the
type case statement is mainly efficiency. Nevertheless, I could live without it
and use only *IS*.
More information about the Oberon
mailing list