[Oberon] Module aliases - what is the correct way to handle them
joerg.straube at iaeth.ch
Fri Feb 14 09:33:38 CET 2020
I agree, leave aliases in and fix the implementation.
Two use cases I know (there are more for sure)
- abbreviation of long module names IMPORT R := RandomNumbersMersenne
I know, not a very strong argument to keep aliases, but handy
- quick exchange of different implementation of the same API
Eg assume you have two different kinds of random number generators: RandomNumbersLCG and RandomNumbersMersenne and you want to experiment with one or the other.
> Am 14.02.2020 um 08:55 schrieb Diego Sardina <dsar at eml.cc>:
> On Fri, Feb 14, 2020, at 8:02 AM, Andreas Pirklbauer wrote:
>> Hi Paul,
>> Some additional comments:
>> 1. First, some history: For decades I was secretely hoping that module
>> aliases would one day go way from the language and that I therefore
>> would ever have to expend scarce brain cycles on such an uninteresting
>> topic. But they didn’t go away - some people seem to find them useful.
> Unfortunately I don't have much time to follow this topic. I didn't read all
> the posts, so maybe someone already mentioned this.
> Import aliasing is a good way to manage multiple implementations, for
> example if one has Stacks64, Stacks128, Stacks256, Stacks512, the import
> would be:
> IMPORT Stacks := Stacks64;
> it's easier to change the implementation by modifying only that line of code
> instead of replacing code in the whole text.
> Also some compiler extensions may implement parametric modules and that
> would allow arguments like:
> IMPORT Stacks := Stacks(64);
> Just for the record, Modula-3 implements generic modules via import aliasing.
> Removing them is not a good idea in my opinion.
> Diego Sardina
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
More information about the Oberon