Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Tricky config framework semantics #201
At least for new-comers to the framework it can be tricky to consistently trigger initialization/update code given a config option's value. Consider this:
So you have to make sure that your initialization happens even when the handler doesn't get called, and you cannot write your handler assuming that the new value is actually different from the old one.
These arguably aren't bugs, but they do take getting used to. Perhaps worth coming up with some design patterns or additional documentation. If we do want to change functionality, we could consider adding a mechanism that lets the user specify that they'd like to see the change handler triggered once at startup, and that they'd like to skip repeat invocations with the same value.
Just to state the obvious - you are obviously right with your example.
The reason that change handlers do get called one time when a configuration file was read, even if there was no change is that it is internally a bit... challenging to figure out if there has been a change between an old value and a new one and I thought it is just safer to get people used to the fact that change-handlers can fire several times.
There is a whole bunch of reasons for that. While for a simple example (e.g. having a boolean) not calling the change handler seems easy, things get a bit more complicated when there are complex datatypes (we don't really have an easy way to compare equality for some of them). Furthermore - some change-handlers will reformat the input data. So the current semantics are "the change handler is called whenever the respective configuration data reader deems it necessary; in case of configuration files they are called when the ascii-representation of the configuration value in the file changes".
In any case - I will add that explanation.
As to the second part - I am in principle happy to add something that calls the change handler once on Bro init with the initialization value. I think this behavior should be opt-in though; it might be only me but I actually like the way that it currently works (you have one kind-of-reasonable value defined on startup and one when things change).
Do you have an idea on the syntax you would like for an opt-in? Or would you be ok with the current behavior just being explained in documentation? I actually don't have especially strong feelings in any direction.
We could not really fire immediately at that point... there might be priorities to take into account.
I think we in that case basically should wait till the end of bro_init (till hopefully the handlers have been populated) and then call them in the normal priority order.
Thinking more about it - I am actually a tiny bit tempted to just keep the current semantics and just expand the documentation. But - that is just my feeling on this.