Re: question about linker

On 02/12/2024 19:27, Bart wrote:

On 02/12/2024 15:24, David Brown wrote:

On 02/12/2024 13:24, Bart wrote:

 

I would consider any kind of automatic import system to be a bad idea.

 It's not automatic; you have to list the modules. If you don't want data shared, then don't export it!
 

As I understood it, or perhaps failed to understand it (after all, it's not as if there are published specifications, references, tutorials or examples for your language), you would list your modules for a program in one place, and then other modules in the program automatically import them all.

If you want selected imports between arbitrary module subsets, then my scheme has 'subprograms' (see below), or you choose a language with a more chaotic module scheme that can give that flexibility, but requires more maintenance.
 

I like structured and modular programming.  It is strange to me that someone would have the tools for that, and then choose not to use them. But some people seem to prefer piling everything together in one name space.

 This point was about individual functions not files. For example this in Python:
    from math import sqrt
 (which also has the effect of making 'sqrt' part of this module's namespace).
 

This is sometimes convenient for functions that you are going to use a lot.  At other times, you use "import math" and then refer to "math.sqrt".

 

Indeed - that's why I say it /sounds/ terrible to me.  As I said above, I prefer a clear and modular organisation.  If I am writing module "foo" and a colleague is writing module "bar" as part of the same program, the last thing we want is automatic import of each other's modules, symbols, functions, etc. - especially not jumbled into the main namespace for the code!

 If you don't then you're not really writing the same part of the program. I mentioned my programs comprise subprograms, which have stricter import rules and which are non-hierarchical/non-circular.
 

If you are linking everything together into one program, it is one program.  (Having a hierarchy within that is fine - but it's still one program.)

It sounds like, in my scheme, you'd be working on different subprograms: each team member has their own chummy collection of modules.
 

Perhaps you simply don't know how teams might work.

But it's possible you are also working on the same collection. Then you talk!
 C for example has one giant namespace anyway that contains all shared entities. /Then/ you have a problem, especially when people avoid 'static'.
>

That's one reason why C programmers don't avoid "static" if they know what they are doing.
And yes, the single shared "external linkage" namespace for a C program is a limitation to scalability and an inconvenience.