Closed phraktle closed 8 years ago
Is there a particular reason for this change? My concern about making it a singleton is that it limits our ability to change the behavior in the future without breaking the API (e.g., if we wanted to make it hold some sort of per-reader state). I do admit it is hard to imagine a reason for such a change, but I am curious is there is a reason for this change.
I expect NoCache to remain a stateless instance (it's basically just a no-op). I also don't expect usage of this directly (since it's the default anyway). The reason why I made this change was there was one static instance of it in the DB Reader and I had to make another one in the GeoIP API as well. With the singleton, that could be updated to use the same instance. Either way, not a big deal, just thought it would be nicer with a proper singleton.
make NoCache a singleton