Vir points out that "queue of callables" is pretty much exactly what a signal
does.
Add unit tests to verify chronological order, also queue reset when fired.
LLSingleton currently presents two different usage styles: deriving MyClass
from LLSingleton<MyClass>, or just using a typedef. Turns out LLGlobalEconomy
is the ONLY class using the typedef style -- and the apologetic comment talks
about a potential maintenance that hasn't actually happened.
Derive LLGlobalEconomy from LLSingleton<LLGlobalEconomy>, like everyone else.
to a new llcommon/llinitdestroyclass.h.
This mechanism is so general -- but has so many related moving parts -- that
(a) it deserves to be in a header file all its own, instead of conflated with
llui.h, and (b) it should be in llcommon where anyone can use it. It has no
dependencies whatsoever on llui or anything viewer-specific.
In this very changeset we changed one #include "llui.h" whose comment admits
that it was only dragged in for LLDestroyClass.
The LLMuteList singleton instance might be requested before gMessageSystem is
constructed. LLMuteList wants to register a couple gMessageSystem callbacks.
Since gMessageSystem is not (yet) itself an LLSingleton, LLMuteList's
constructor can't just call it into existence. Until now, LLMuteList overrode
LLSingleton's getInstance() method: every time getInstance() was called, the
subclass override method would check whether gMessageSystem had been
initialized, and if so, register its callbacks before forwarding the call to
the base-class LLSingleton::getInstance() method.
Change to use LLPounceable::callWhenReady() instead.
This is the reason gMessageSystem was made an LLPounceable.
Now that gMessageSystem is an LLPounceable, we would either have to define
comparisons to LLPounceable's held type or static_cast<LLMessageSystem*> to
literally compare to NULL. But since we already define operator bool(), that's
the easy (and idiomatic) fix.
LLMuteList, an LLSingleton, overrides its getInstance() method to intercept
control every time a consumer wants LLMuteList. This "polling" is to notice
when gMessageSystem becomes non-NULL, and register a couple callbacks on it.
Unfortunately there are a couple ways to request the LLMuteList instance
without specifically calling the subclass getInstance(), which would bypass
that logic. Moreover, the polling feels a bit dubious to start with.
LLPounceable<T*> presents an idiom in which you can callWhenReady(callable) on
the LLPounceable instance. If the T* is already non-NULL, it calls the
callable immediately; otherwise it enqueues it for when the T* is set
non-NULL. (This lets you "pounce" on the T* as soon as it becomes available,
hence the name.) So if gMessageSystem were an LLPounceable<LLMessageSystem*>,
LLMuteList's constructor could simply call gMessageSystem.callWhenReady() and
relax: the callbacks would be registered either on LLMuteList construction or
LLMessageSystem initialization, whichever comes later.
LLPounceable comes with its very own set of unit tests. However, as of this
commit it is not yet used in actual viewer code.
Remove evil getIfExists() method, used by no one.
Remove evil destroyed() method, used in exactly three places -- one of which
is a test. Replace with equally evil instanceExists() method, which is used
EVERYWHERE -- sigh.
Nat Goodspeed