Le 09/04/2015 16:10, stepharo a écrit :
Le 7/4/15 15:19, Thierry Goubier a écrit :
Le 07/04/2015 15:14, Tudor Girba a écrit :
This setting should be removed. Does anyone have anything against that?
Or, could settings be rewritten so that we don't regularly triggers
DNUs and MNUs when we reload them?
You know, just regular, declarative, boring settings instead of
something which execute code on non-existent Classes half of the time...
We started to extract tge configuration code out of pillar but we do not
know if it will work for settings.
So far no time to check.
It is called cocoon on pharoextras
Seems fine. Just browsing through it.
Maybe a tad complex, to have to subclass both a CCConfiguration and a
CCSTONConfigurationInterpreter for the thing to work. Flexible and
powerfull. Composable.
Is missing some of the code needed for settings: a default place to
store them, the GUI part (settings browser), and the logic run-once.
As the previous one, gives the feeling that settings are not application
driven, but system driven (and applications are passive receivers). It's
a design choice, and I'm not entirely happy with that choice, because it
has a tendency to force decoupling layers in apps so that they can
control if and when they take in account external settings or in-image
settings changes.
Thierry
