[Oberon] Intermediate scopes in Oberon-07
Andreas Pirklbauer
andreas_pirklbauer at yahoo.com
Sun Feb 11 05:06:50 CET 2018
> From: Chris Burrows chris at cfbsoftware.com on Sun Feb 11 CET 2018
>
> What I am really interested in is seeing some other existing
> code examples where the advantage of having a local TYPE is
> much more obvious and an alternative solution is not feasible.
It all boils down to the old question of what one should consider as
the “wall” to clients for information hiding and abstraction purposes.
Historically, it was ALGOL which had introduced the notions of limited
scopes (=limited visibility) of identifiers and of the temporary existence
(=limited lifetime) of objects such as variables or procedures. The notion
of a procedure is closely tied to that of allocation of its local variables.
MODULA then added a second scoping structure, the module. It is similar
to a procedure in many ways, but unlike a procedure, no allocation is
associated with a module, i.e. visibility is not affected. Modules merely
constitute a “wall" around its local objects which *may* be exported.
The introduction of a second scoping structure (module) raised a question:
what is (or should be) the actual “fence" to clients?
The general consensus today is that it is the module, not the procedure.
The idea to allow local (nested) procedures only adds some spice to this
debate, but in essence information hiding remains the business of modules.
*If* one accepts that, information hiding is preserved even when types used
only in a procedure are declared globally within the module.
Now you can see one of the reasons why I dislike local procedures: now we
have N > 2 scopes to deal with, when many programmers (or students) already
have difficulty understanding the difference between the two principal ones
(module, global procedure). This is also bad from a pedagogical perspective.
AP
PS: The paper which originally introduced the module concept in 1972 is still
one of the best sources on this topic (David Parnas, “On the Criteria To Be
Used in Decomposing Systems into Modules”, Comm. ACM 15, 12 Dec. 1972, 1053-1058)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20180211/e8d7aa7c/attachment.html>
More information about the Oberon
mailing list