[Oberon] Oberon for a C++ user.
Alexander Ilin
ajsoft at yandex.ru
Wed Nov 16 08:37:42 CET 2016
Hello!
>> If at a later point you change the RECORD definition to become an extension of a more generic object, the compiler will help you resolve the method name conflicts.
>
> Why I have to change record definition to be an
> extension of a more generic object? That means
> there was something wrong in my design decisions.
Are you saying you're never wrong the first time 'round?
> There is also a lot of work, i.e. implementing
> all the mandatory part of the interface.
> NEW keyword of course helps here in the case of
> clashing names, but putting an independent type
> into a type hierarchy is easier to state than
> to do. In most cases, it requires a re-design
A redesign? Why not gradual evolution of a design?
POINT 1: Initial design.
TYPE
MyData = RECORD ... END;
PROCEDURE (VAR this: MyData) Store (VAR file: Streams.Stream), NEW; (* Oh, no! A useless keyword! *)
BEGIN ... END Store;
POINT 2: New object introduced.
TYPE
MyData = RECORD ... END;
MyData2 = RECORD ... END;
PROCEDURE (VAR this: MyData) Store (VAR file: Streams.Stream), NEW;
BEGIN ... END Store;
PROCEDURE (VAR this: MyData2) Store (VAR file: Streams.Stream), NEW; (* Shucks! Now we've got two of those! *)
BEGIN ... END Store;
POINT 3: Generalization is in order.
TYPE
Storable = RECORD ... END;
MyData = RECORD (Storable) ... END;
MyData2 = RECORD (Storable) ... END;
PROCEDURE (VAR this: Storable) Store (VAR file: Streams.Stream), NEW;
BEGIN ... END Store;
PROCEDURE (VAR this: MyData) Store (VAR file: Streams.Stream); (* That's better! *)
BEGIN ... END Store;
PROCEDURE (VAR this: MyData2) Store (VAR file: Streams.Stream); (* Got rid of the buggers! *)
BEGIN ... END Store;
At this point the compiler demands removal of the two "NEW" qualifiers,
thus bringing to the programmer's attention all the places where code
needs to be updated in the face of the new object hierarchy.
It's the long-term evolution of the codebase that's being helped by
the compiler here, which is a rare feat even these days.
---=====---
Александр
More information about the Oberon
mailing list