Have you considered to yield (an) proxy object(s) instead of the actual Singleton in uniqueInstance? This way it suffices to update the proxy with each update of the code.
Am 3. Januar 2019 15:36:27 MEZ schrieb Ben Coman <b...@openinworld.com>: >On Thu, 3 Jan 2019 at 20:01, Konrad Hinsen via Pharo-users < >pharo-users@lists.pharo.org> wrote: > >> Dear Pharo experts, >> >> I am wondering if there is a good way to deal with singleton objects >> whose value needs to be updated following changes in the code that >> initializes it. >> >> Following the model of many examples in Pharo itself, I have defined >a >> singleton class with a uniqueInstance method for accessing (and >creating >> if necessary) the single instance, and a method "reset" marked as a >> script to set the uniqueInstance back to nil when required, i.e. >after >> source code changes make the prior value inappropriate. >> >> This works very well, as long as I don't forget to do the reset, >which >> has already caused me a few hours of debugging time. Worse, suppose >> someone else is using my project in progress, pulling changes from my >> GitHub repo once per week. That person cannot know if the latest >changes >> require a singleton reset. More importantly, users shouldn't have to >> know about such internal details at all. >> >> So is there a way to do the reset automatically whenever a new >version >> of my package is loaded into an image? >> >> Thanks in advance, >> Konrad. >> > >You might use a Baseline #postLoadDoIt: >https://github.com/pharo-open-documentation/pharo-wiki/blob/master/General/Baselines.md > > >Consider that a person pulling your changes cannot know if you have >upgraded the library versions of any dependencies, >so always updating via a Baseline might be a reasonable expectation. > >But that doesn't help you while developing within the one image. > >cheers -ben
