Hans Klaver wrote:
> Since the transition of Oberon/F to BlackBox/Component Pascal the use of
> super calls is strongly discouraged (and may no longer be supported in
> future versions ). [snip]
> This is why the procedures Externalize and Internalize in module Stores
> should be regarded as EMPTY (actually they are EXTENSIBLE for compatibility
> reasons) They should not be called but only extended (implemented) by
> inheriting object types (which only inherit their interface).
>
Hans:
I know, but you have not quite answered my question. If OuS discourage
supercalls, what do they recommend as an alternative? I have not found
any concrete substitute in their docs.
I read Wolfgang's Graph again and discovered he works around the problem
by a little bit of cheating:
MODULE GraphModels (my own translation);
TYPE
Figure = ABSTRACT RECORD (Stores.Store) l,t,r,b END;
Model = RECORD (Models.Model) (*list of Figures*) END:
END GraphModels.
Now, he does not have to supercall Figure's store/load because
in Graph it is the *model* that stores l,t,r,b's of all Figures,
and therefore Figures do not have anything to store/load,
and therefore their store/load methods do not need to be
supercalled! But that is cheating, not a general solution.
In general, the base class will have some data fields (or else
there is no need for a base class), whose storing/loading
should be the responsibility of the class itself, not of its container.
In my case I have 3-level deep class structure: I am extending
Wolfgang tutorial Graph with an intermediate Object who holds
colors, line type, etc, etc. At the concrete level one below Object
I have Curve and Histogram that use Object's common data fields
and add their own fields. Wolfgang solution does not work
anymore.
Thus, my question is: if not supercalls, then what?
If OuS do not propose their concrete alternative to supercalls,
then their recommendantion not to use supercalls does not
make any sense.
Wojtek
Received on Mon Feb 15 1999 - 19:10:55 UTC