[Oberon] Serious type loophole in type case statements and a possible fix
luke.boasso at gmail.com
Fri Oct 30 18:53:50 CET 2020
the restrictions seems reasonable but they add quirks to a mostly regular
language, take time to understand and explain to a beginner.
It feels like they are not in the spirit of Oberon...all because of fear of
missing out on performance?
On Fri, Oct 30, 2020 at 12:38 PM Andreas Pirklbauer <
andreas_pirklbauer at yahoo.com> wrote:
> 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
> branch of the case statement. But yes, using a local variable is always
> >> 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
> > 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*.
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Oberon