On Tue, 03 Jan 2012 13:50:11 -0800, Brion Vibber brion@pobox.com wrote:
I've reverted a number of recent commits to the Title class which added several more pre-cached fields to it, as I really don't think we want that sort of data in Title objects to begin with. A Title object is meant to represent a... well, a page title :) and as such should be roughly equivalent to passing the string-form title around, but without having to parse and de-parse the items all the time.
Since ancient times we've had a couple things like an article ID being saved into local state, which is frequently useful to optimize lookups but has its own problems (it has to be explicitly cleared or reset from time to time). These really belong more in a 'Page' object than a 'Title' however.
These days we've got a WikiPage class which has been further split from Article as well; it seems to me that these sorts of things might belong better there than in Title. Thoughts?
-- brion
Sure. Though I don't like the way we're currently passing around a WikiPage instance as a completely separate entity from the Title when the WikiPage isn't supposed to have any state of it's own that would make it reasonable to have any more than one WikiPage instance per title. ((We have constructors being created with formats like ( Page $page, IContextSource $context = null ) where a WikiPage instance is being passed despite the fact that the context should already contain enough information))
We may want to remedy that first either by adding a getWikiPage to IContextSource or by making a WikiPage method that will return a singleton-per-title.