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