On 2/5/26 9:26 AM, Thomas Lamprecht wrote:
Am 05.02.26 um 08:50 schrieb Dominik Csapak:
On 2/4/26 4:45 PM, Thomas Lamprecht wrote:
Am 04.02.26 um 11:04 schrieb Dominik Csapak:
[snip]
+initialize_cpu_models();
this now still always does this on module load, would be nicer to actually
only pay for that if needed by adding getter methods for each variable, like
sub get_all_cpu_models {
initialize_cpu_models() if !defined($all_cpu_models);
return $all_cpu_models;
}
Same with a get_cpu_models_by_arch getter.
not sure if that gains us anything, since we need the 'all_cpu_models' hash
statically for the 'reported-model' enum of $cpu_fmt, so even if i put it in a
getter, it would still get initialized on module load...
It still nicer to have, especially if this would be decoupled in the future.
Else we can stop clean separation and just always initialize everything
globally everywhere, to exaggerate for the points sake.
sure, makes sense
also not sure if having two seperate getters make sense, since
the 'all_cpu_models' one depends on the cpu_models_by_arch one.
I'm not sure if I see what a data dependency has to do with not having
a cleaner getter interface to better encapsulate that local variable off
and hedge against someone just making it an "our" shared variable in the
future. A shared initialization code path doesn't IMO mean that one has
to couple using the result of that together.
So in that case we'd have to initialize both anyway (again, on module load).
Yes, but that's just a detail of the current implementation, not–to over
play the point–making it ugly because it doesn't matter *now* for the
*current* use case. Even there it's nicer to not have a module wide
variable used directly, as for all but small scripts that seldomly makes
code more readable.
so this would make code a bit more complicated, but I don't really see the gain
here.
How is having a getter and making the initialization a local "my sub"
complicated? I basically provided the getter code for one variable
already, the other one is basically just a copy of that, and adaption
to using these getter's should be straight forward..
ok, complicated was the wrong choice of words here, what i meant
was 'more code and a longer diff', but yeah this is often not the
best metric for such things.
if we'd want to be able to reinitialize (for the tests) we can't make
it really 'my sub', or did you mean that for the tests we override
the getter instead?
(just to summarize) the actual reason we need this to be changable/
overwriteable is that the 'host' cpu type model only exists for the host
architecture. This can't normally change after the module is loaded,
except when running tests, since the host arch can change between them.
or is there a way in perl to call a 'my sub' from external or
can we 'reload' a module in a way the variables are 'cleared'?
btw., now that I'm thinking more of this, might be even nicer to clean
this up even slightly more and produce a minimal CPUModels perl module
on build time, as the info won't ever change during run time, and for
testing it should make it even easier to override things there.
And then these could be constants, where I would not care that much
anymore about directly accessing them, but won't help testing and
using constants over getters is IMO not really cleaner for non-scalar
values most of the time (as always there certainly are exceptions).
I can refactor the models into their own module of course, I'd
just like to settle on a way to do things.
I'd either
* like you first suggested, do a common initialization helper that can
be called externally (for the tests) and a getter for the
cpu_models_by_arch with an arch parameter and a getter for
'all_cpu_models'
* have a small (perl?) script that generates the perl module during
build with the correct cpu models that provides either constants
to use, or similar getters as above.
in that case each test case would need to regenerate and reload
that perl module for each test somehow (e.g. interpolating
the output directly from the generation script?)
I'd tend to the first one since it sounds easier to do and as you said,
having getters is often better, or did I misunderstand your suggestions?
