On Tue, 03 Jan 2012 13:50:11 -0800, Brion Vibber <brion(a)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
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
has its own problems (it has to be explicitly cleared or reset from time
time). These really belong more in a 'Page' object than a 'Title'
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?
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
We may want to remedy that first either by adding a getWikiPage to
IContextSource or by making a WikiPage method that will return a
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name