> 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