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.
> 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..
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).
