[nama] costs and benefits of singletons
- From: Joel Roth <joelz@xxxxxxxxx>
- To: nama@xxxxxxxxxxxxx
- Date: Mon, 22 Aug 2011 01:23:01 -1000
Nama has 260 global variables.
They are categorized in the file 'variables.sorted.txt'
which generates as part of the build process,
However I am considering containing these variables
in various singleton objects such as
$effect_cache or $engine
One way is to keep the exact semantics, no objects,
just reorganize the names
$run_time $engine->runtime_limit
Changing an the variables to hash values might seem an
option, but turns out to be bad
@loop_endpoints $engine->{loop_endpoints} # ???
This breaks assignment semantics (at least in
older perls) because the data
structure changes from array to array-ref
$project_name $project->name
# the object serves to categorize, and an
# easy way to dump contents for introspection
$project_name = "gladiolis" # existing code
$project->name = "gladiolis" # object can provide an lvalue!
Moose can provide an lvalue by installing
MooseX::Meta::Attribute::Lvalue
Or by one-line change to existing Object::Tiny based code!
Now out of 260 variables, I've renamed 54. The point
is that most or all variables will join the singularity without
changing the semantics of array and hash assignment.
Including assignments during restore.
Will only need to check for collisions of names without
sigils.
Overall, the source code will expand in size, and may become
slightly slower due to additional object accesses.
That is the result of a year's meditation on Nama's global
variables.
Thanks, patient readers
--
Joel Roth
Other related posts:
