There are many good points against common use of exportall: possible name conflicts when importing from different packages with explicit export, we know what symbols are intended for internal uses only, and what are intended for external uses However, these arguments might not be suitable for som…

[image] jsjie: However, for something like physical constants - which might be defined as macro in C - are there better, simple way to do this? You can write const h = 6.62607015e−34 and you don’t have to worry about it being global anymore as the compiler can infer its type (as it can’t ch…

[image] jsjie: Currently, I have a submodule called PhysicalConstants , and I’m left with three choices: Shameless self-plug: did you see PhysicalConstants.jl ?

[image] jsjie: global variables are also commonly regard as bad To be clear, non-constant globals are commonly regarded as bad. Constant globals are perfectly fine: Performance Tips · The Julia Language

Yes, I checked it when I began my project, and found it had rich features like different codata versions, uncertainty data and so on, which seemed to be an overkill, so I didn’t use it then. But I’m considering to turn to it now. Back to the main topic, I checked your repo and found constants are…

To be clear here, what I was referring to was constantly reading & writing those globals. The compiler can’t make that more efficient, even if it could in some circumstances when the variable would not be a global, because it should ensure that the value is actually being written to the global. This…

In my opinion, what matters more is not whether the variable is read/written once or constantly, but whether it is read-only, or can be changed. Physical constans, as discussed here, should be read-only, but may be read frequently. I think that the compiler can do much to optimize read-only variabl…

You can export all symbols (or a subset) as follows: jump-dev/JuMP.jl/blob/f233dd11677b8164c509ebf4a1be16971933b4cf/src/JuMP.jl#L1379-L1402 # JuMP exports everything except internal symbols, which are defined as those # whose name starts with an underscore.…

[image] jsjie: Physical constans, as discussed here, should be read-only, but may be read frequently. I think that the compiler can do much to optimize read-only variables, but in Julia, it seems that we cannot inform compiler about this? There is const for these and for immutable constants …

Exportall might be useful in some (limited) cases?

Internals & Design

jsjie May 13, 2022, 3:12am 6

Someone definitely have different ideas, can see this post

Topic		Replies	Views
Exportall? General Usage question	22	9651	September 26, 2024
Global constants General Usage question , constants	6	303	December 23, 2024
Is an explicit "export" a good thing? General Usage	51	6091	December 7, 2017
Opinions for exporting common names General Usage namespaces	29	1551	July 23, 2021
"Importing" all "exported" functionality General Usage question , module	2	540	December 30, 2022

Exportall might be useful in some (limited) cases?

Related topics