[Oberon] Clarifying type compatibility in Oberon-07
joerg.straube at iaeth.ch
Fri Oct 6 13:20:09 CEST 2017
nbrOfBirthsPerMonth: ARRAY 12 OF INTEGER;
nbrOfAccidentsPerMonth: ARRAY 12 OF INTEGER;
nbrOfBirthPerMonth := nbrOfAccidentsPerMonth (* these match structurally but makes not much sense, should be forbidden *)
If you want to write a generic module handling monthly statistics, you have open ARRAYs and the exceptions for assignments of actual to formal.
PROCEDURE StoreYear (a: ARRAY OF INTEGER); (* … *)
StoreYear (nbrOfBirthsPerMonth); (* structural match *)
If you have a procedure like StoreBirths (); you should not use open ARRAYs, as then StoreBirths (nbrOfAccidentsPerMonth) would be possible…
Von: Oberon <oberon-bounces at lists.inf.ethz.ch> im Auftrag von Andreas Pirklbauer <andreas_pirklbauer at yahoo.com>
Antworten an: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
Datum: Freitag, 6. Oktober 2017 um 13:17
An: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
Betreff: [Oberon] Clarifying type compatibility in Oberon-07
> Personally, I’m not indifferent ☺ > > I know that it can be done, but the question is WHY.
> Only because something can be done is a poor reason to do it.
> > > If you put a := b in your code, you do that as you know or
> assume a certain relationship between those two variables
> (they e.g. represent instances of the same or comparable
> thing). If this hold true, I don’t understand why you
> have to write two totally independent type declarations
> that (by accident) match structurally. > > br > > Jörg
Jörg, you have a valid point - no question! I value such input. As
I said myself earlier “I just don’t have a good enough reason yet”.
But I do want to continue exploring the question a little bit, now
that the topic has come up for the N-th time in M decades. Perhaps
this time around, someone comes up with a new insight or a “good
enough” reason for changing the language.
If I understand you correctly, your position can also be viewed
as: “If as a language designer one does have a chance or option
to promote ‘good’ programming style (whatever that means), one
should by all means use it”.. In the particular case of array
type equivalence discussed in this forum, it effectively amounts
to forcing programmers to write one type declaration instead of two;
which I too view as good programming practice, which in addition
increases code readability in my opinion.
Perhaps yet another way to look at your position is this: Once I do
allow structural equivalence for arrays, I can never go back in the
future without breaking someone’s legacy code. So, in the absence
of a really compelling reason to actually *allow* structural
equivalence for arrays, one should “play safe” and disallow it.
Perhaps that is what the Pascal/Modula/Oberon compiler writers
felt all those years..
PS: I’m now 60/40 - does that make you feel better? ;-)
-- Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Oberon