Marcus you should not stress about extra packages.
Because we will have deadcode if you unload the setting core and the
settings methods are in the same package.
I think that they are more problem with fonts for example and it would
be better to focus on them.
did you read these:
https://github.com/pharo-project/pharo-workingRoadmaps
Stef
Hi,
The Settings framework is very nice: there are no dependencies to the framework
itself anywhere, so you can run
with both the Setting Browser and *the framework itself* unloaded.
All the settings definitions are in their own packages, so you can even unload
*those*. But I wonder if that is not one
thing too much:
-> the definition itself does not create dependencies at all
-> the definitions are *tiny* (5-30 line methods)
-> the packages contains just one class with (often) just one method,
managing a complete package for that should pay of,
and I would say it does not (“I can save 500 bytes of dead code by not
shipping the settings definition in my deployment image!").
I guess nobody ever unloaded a settings package for deployment!
(#cleanUpForProduction does not)
I would like to move the definitions of settings close to the code that the
settings manipulate (and from it’s own class
just to the main class of that package, class side).
- you can still unload the settings framework after
- the only “useless” things staying in the system after unloading the
settings framework is a method that is not used
(but that does not introduce dependencies)
- managing the code base in turn gets simpler
- less classes and packages to manage
Marcus
