[Oberon] IMPORT Modules: why does order matter?
Richard Hable
informujo at aon.at
Mon Mar 4 13:44:15 CET 2019
OK, now this makes the technical restriction bearable! After all, a real
change of interfaces will always lead to outdated object files and the
necessity to recompile. One might as well adapt the import order in the
process…
Thank's for the clarification!
Richard
On 03.03.19 23:14, Jörg wrote:
> Richard
>
> The important assumption in your description is „which does not change the interface“. As long as this is true, you don‘t have to reorder your original import sequence.
> As long as X does not suddenly re-export things from Y everything is as expected. But this re-export thing would change the interface...
>
> Jörg
>
>> Am 03.03.2019 um 16:13 schrieb Richard Hable <informujo at aon.at>:
>>
>>> On 03.03.19 00:13, Andreas Pirklbauer wrote:
>>>
>>> But the question is whether one *should* allow imports to be declared
>>> in *any* order. This could be endlessly debated...
>>
>> Really?
>>
>> To me it seems completely clear that the user of modules should *not*
>> have to know about (hidden) implementation details like dependencies
>> between those modules.
>>
>> Let’s say, I explicitly use the services of some third-party modules X
>> and Y in my code. I import them in the order X, Y and everything works fine.
>>
>> One day, the implementor of X and Y decides to do a refactoring, which
>> does not change the interfaces of the modules, but leads to a dependency
>> between those modules: X now imports Y.
>>
>> And suddenly, for no good reason, my module does not compile anymore.
>>
>> Richard
>> --
>> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
>> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
More information about the Oberon
mailing list