[Oberon] Life without local procedures

Richard Hable informujo at aon.at
Sat Feb 24 00:01:17 CET 2018


On 2018-02-23 12:57, Jörg wrote:

> Personal style:
> What I don't like with local procedures is the following:
> As the local procedure(s) sit between the variable declaration and the
> BEGIN, the local variable declarations are so far away from the BEGIN. I
> don't like to scroll...

I think, this already contains part of the answer to the question when
*not* to use local procedures:

If a local procedure uses local declarations (usually parameters or
variables) of the surrounding procedure, the position of the local
procedure makes perfect sense: you want to read first what you access
later.

If the local procedure does not use anything of the surrounding
procedure, but depends only on its own local declarations and possibly
on global declarations, the local procedure declaration can feel like an
obstacle between the declarations and usages of the surrounding procedure.

> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of Chris
> Burrows
...
> However, what I would be really interested to know is in what circumstances
> you would *not* make a procedure local if it *could* be made local. 

I think, the main criteria should not be, if it is technically possible
to make a procedure local because it is only used in one other
procedure. Instead, the main question should be whether a procedure
logically belongs to a single other procedure or is independent enough
to be (potentially) reused elsewhere.

Of course, if a procedure is written to use declarations of the
surrounding procedure, the programmer has already decided to implement
it in a way that it is only usable within this procedure.

But also if a procedure is technically independent of the calling
procedure and could therefore be moved outside, it may make assumptions
which only make sense in the context of the caller. Also then it should
be made local to clearly state its limited applicability.

On the other hand, procedures which perform a general task should
definitly *not* be local, even if they happen to be called only within a
single procedure.

BTW, I finally found a solution for local methods in Java:

While it is not possible to declare methods within methods, it is
actually possible to declare local classes within methods. Therefore, I
declared a local class with my "local" methods and then created a single
instance of the local class to invoke them. Since methods within the
local class can also access variables declared in the surrounding
method, this allows for access to "intermediate" variables.

While this seems weird at first sight, it is actually quite logical: in
Java every method belongs to a class; thus, one can not just add new
methods within a limited scope, but needs a separate class to collect them.


More information about the Oberon mailing list