>>
>> P.S.:
>> One of the difficulties I had at first was in understanding the difference
>> between super call and up-calls. A super call is a call to a super class
>> (base class, lower down in the module hierarchy), an up-call is a call to a
>> sub class (higher up in the module hierarchy). So: up-call = "sub call" (#
>> super call).
>> A framework like BlackBox heavily relies upon up-calls but tries to avoid
>> super calls!
>>
>While the above statement may be technically correct, it mixes two
>notions and thus confuses the issue even more.
>
>A normal subroutine call is a "down call" since a procedure higher up
>in the module chain is calling a procedure lower in the module chain.
>With procedure variables and overridden methods, it becomes possible for
>a module to invoke a procedure higher up in the module chain, or an "up
>call". Such up calls are prevelant in framework systems, which are
>unfinished by definition and comleted into a working system by
>application specific procedures.
>
>It is possible to discuss "up" and "down" calls without any reference to
>object oriented programming.
>
OK, agreed.
I had no difficulty in grasping the difference between down-call and
up-call. When I learned about super calls later on I didn't know where
these fitted into that scheme. The problem I had was more of a linguistic
nature: in my feeling the term super call denotes something in an upward
direction, whereas in reality it is a special kind of down-call, and
certainly no up-call.
Object oriented programming has crept into our minds more than you would
think: also you refer to OOP in mentioning the term "overridden methods".
Books on Oberon (Reiser & Wirth, Mössenböck) make use of terms from the
domains of both procedural programming and object oriented programming.
This can sometimes be a bit confusing to students of the language, at least
to me it was...
Hans Klaver
Received on Mon Feb 15 1999 - 19:54:36 UTC