this init function only is suitable for non-distributed configurations,
but is probably still worthwhile to have something like this as it
helps remove boilerplate in applications where only a simple config
is needed anyway.
adding shutdown is mostly useful for applications using component/mount
another potentially contentious change.
the idea here is based on my inability to come up with a reason why
each library providing an IView implementation (e.g. views-honeysql)
would need a different function for this. in fact, i'd argue that it's
probably a better idea to have all the hints going to a single
"dispatch" function anyway (aka. this put-hints-fn) and have it check
for any metadata on incoming hints and do any custom processing there.
the IView implementation libraries have this ability already to add any
kind of custom metadata to hints anyway.
i don't think anything is lost by this change personally, and it
removes the need to call multiple functions to set a custom put-hints-fn
for each IView library that a project might need.
tl;dr - i like simpler configuration. this change is the beginning
of stuff that helps me do that in the future.
also as a nice bonus, this stops the debug log call here from spamming
up the log if the refresh-watcher thread is running on a frequent
timer interval
why do this?
well, i think the biggest gain from the perspective of a developer
looking to use this library is that this simplifies the use of it.
it becomes easier to change things in this library (and also in others
that plug into it, such as views-honeysql and other libraries providing
alternate IView implementations) to have a much better out-of-the-box
working configuration for the common use-cases.
additionally, i could not think of a scenario where i would want to
have more then one view-system hanging around given that you can
plug in multiple different IView implementations into the same
view-system that potentially each work with a different backing
database.
the big complaint i could see against this change is that it goes
somewhat against a "functional approach" with the global state that is
used automatically by the functions in the library.
personally, i (right now) see it as a more _practical_ approach. and
for me that wins out in the end.
who knows, perhaps i will deeply regret this change down the road.
Gered
