[Oberon] Module aliases - what is the correct way to handle them

[Jörg]

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.

br
Jörg

> 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
> https://lists.inf.ethz.ch/mailman/listinfo/oberon