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

Skulski, Wojciech skulski at pas.rochester.edu
Fri Feb 14 17:27:00 CET 2020


I add another useful case.

IMPORT S := System;

Use "S.Close S.Grow" etc in the menus. They will become shorter.

There is perhaps another way of doing the same, so it may not be a strong argument.

Wojtek 
________________________________________
From: Oberon [oberon-bounces at lists.inf.ethz.ch] on behalf of Jörg [joerg.straube at iaeth.ch]
Sent: Friday, February 14, 2020 3:33 AM
To: ETH Oberon and related systems
Subject: Re: [Oberon] Module aliases - what is the correct way to handle them

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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.inf.ethz.ch_mailman_listinfo_oberon&d=DwIGaQ&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=RgetQBccH-veBxygXa_cnoGLSuIlmZuVSp9r-0E7RsU&s=DRLaoaYNEJkBKVc43xgHf6I55s3gRYm6UhLrXDmuxuw&e=

--
Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.inf.ethz.ch_mailman_listinfo_oberon&d=DwIGaQ&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=RgetQBccH-veBxygXa_cnoGLSuIlmZuVSp9r-0E7RsU&s=DRLaoaYNEJkBKVc43xgHf6I55s3gRYm6UhLrXDmuxuw&e=


More information about the Oberon mailing list