Item5673: should the if Parser and queryParser 'pseudo singletons' be undef'd in the finish() destructors?
Priority: Low
Current State: Needs Developer
Released In: n/a
Target Release: patch
or should we make it clear that they are going to persist for some unknown time.
--
TWiki:Main/SvenDowideit - 01 Jun 2008
Not sure why you think of them as "pseudo". They are singletons, that happen to be lazily created. They contain no internal state, so as written, there is no reason to destroy them. Of course that might change if you follow up on adding operators dynamically (something I like less and less the more I think about it, BTW)
--
TWiki:Main.CrawfordCurrie - 02 Jun 2008
They're pseudo-singletons because they are not 'properly coded' singletons - if you want to use one in a Plugin, the current code would result in another parser being created (unless the coder is fully aware of the core code's usage).
rather than littering any client code with
unless defined, call new TWiki::IfParser
the
IfParser class should be a
proper singleton class? (assuming that it really is supposed to be a singleton).
The fact that one of them is stored in a twiki context, rather than in the session hash, also adds to this confusion - we need to reduce the number of places we store hidden objects, not increase them.
I guess these are code refactorings that will have to wait for 5.0.
--
SvenDowideit - 03 Jun 2008
That's a fair point. TBH I had never considered that these classes would be used outside the core, but in a spirit of modularisation this refactoring ought to be undertaken. However the priority is, IMHO, Low.
--
CrawfordCurrie - 03 Jun 2008