[Oberon] Clarifying type compatibility in Oberon-07
andreas_pirklbauer at yahoo.com
Wed Oct 11 10:27:35 CEST 2017
> On Wed Oct 11 07:59:12 CEST 2017 Jürg Straube wrote:
> Indeed I liked the idea of removing type aliasing in Oberon-07, but it was
> reintroduced in the previous year. Wirth justified it saying that sometimes
> it's useful to introduce a short synonym for a lengthy, imported type name.
> Most prominent example of type aliasing with basic types is TYPE LONGINT = INTEGER;
I should have left the variant *with* the type aliases for INTEGER out. Because the
issue we are discussing here even exists *without* aliases, as the (re-posted) question
below shows. Type aliases only add an additional complication or consideration.
How is this code (“code A”):
nbrOfBirthsPerMonth: ARRAY 12 OF INTEGER;
nbrOfAccidentsPerMonth: ARRAY 12 OF INTEGER;
nbrOfBirthsPerMonth := nbrOfAccidentsPerMonth; (*these match structurally but makes not much sense, should be forbidden*)
CONCEPTUALLY different from the following code (“code B”):
nbrOfBirthsPerMonth := nbrOfAccidentsPerMonth; (*allowed, but *also* makes not much sense*)
when in comes to name equivalence vs structural equivalence?"
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Oberon