New Issue: Should there be a way for module authors to prevent/discourage 'use' of their modules?

e-kayrakli1 · April 14, 2022, 7:38pm

19633, "e-kayrakli", "Should there be a way for module authors to prevent/discourage 'use' of their modules?", "2022-04-14T19:37:55Z"

github.com/chapel-lang/chapel

Should there be a way for module authors to prevent/discourage `use` of their modules?

opened 07:37PM - 14 Apr 22 UTC

e-kayrakli

type: Design area: Language

`use` vs `import` based programming topics come up pretty often while discussing… standalone function names in standard modules. The most recent of such a case were `copy`, `rename` and `remove` functions in the FileSystem module. If that module was `use`d, one can write `copy(src="foo", dest="bar")` which means copy the file `foo` into file `bar`. But that's not clear at all. Do we want a way to prevent or discourage such module to be `use`d? I can think of: - Prevention: think of adding something new to the language to allow something like `qualified module FileSystem`, which allows only qualified "use", ie, import. - Encouragement: maybe we can add annotation that can generate warnings as appropriate: ```chapel pragma "prefer import" // can't recall the annotation syntax we decided on. If we did, that is. module FileSystem { } ``` which can generate some warnings that can be squashed for `use FileSystem`, for example.

use vs import based programming topics come up pretty often while discussing standalone function names in standard modules. The most recent of such a case were copy, rename and remove functions in the FileSystem module. If that module was used, one can write copy(src="foo", dest="bar") which means copy the file foo into file bar. But that's not clear at all.

Do we want a way to prevent or discourage such module to be used? I can think of:

Prevention: think of adding something new to the language to allow something like qualified module FileSystem, which allows only qualified "use", ie, import.
Encouragement: maybe we can add annotation that can generate warnings as appropriate:

pragma "prefer import" // can't recall the annotation syntax we decided on. If we did, that is.
module FileSystem {

}

which can generate some warnings that can be squashed for use FileSystem, for example.