-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Theoretically speaking, these two classes have very distinct roles. MessageCache is a cache of messages, where userland code should run off to get messages from. Language, while containing messages, defers this responsibility to MessageCache, and instead lets users call language-specific behavior like formatting dates. So, in theory, while MessageCache is dependent on Language, Language should not be dependent on MessageCache.
In reality, however, this is not the case. Certain functions in the Language objects will occasionally need to call getMessageFromDB (which calls the wfMsg* functions which call the MessageCache) to grab a possibly customized message. The whole thing is terribly convoluted and I'm not sure I understand.
I'm wondering, however, how this would be restructured if you had to chance to refactor this triumvirate of files without any regard to backwards-compatibility. Some questions:
* A global function is currently being used to do parameter substitution: if you were to stuff this in a class, which class would go into? * The message cache is currently used by extension authors to add their own customizable messages to the mix. Is adding the messages straight to the cache the right thing to do, even if it is labeled mExtensionMessages? Would the cache be responsible for message retrieval? Should the class be renamed for sake of truthfulness? * The cache is language aware in that it can accept messages for specific languages but then figure out which one to use once based on $wgContLang or $wgLang (whichever is currently taking precedence).
It appears that MessageCache is not so much a cache but a loose confederation of tools for *getting* messages, performing some magic along with the global functions to figure out where to look, its own cache being only one of many places to look. Which is why I'm having trouble figuring this stuff out.
Edward Z. Yang wrote:
Theoretically speaking, these two classes have very distinct roles. MessageCache is a cache of messages, where userland code should run off to get messages from. Language, while containing messages, defers this responsibility to MessageCache, and instead lets users call language-specific behavior like formatting dates. So, in theory, while MessageCache is dependent on Language, Language should not be dependent on MessageCache.
In reality, however, this is not the case. Certain functions in the Language objects will occasionally need to call getMessageFromDB (which calls the wfMsg* functions which call the MessageCache) to grab a possibly customized message. The whole thing is terribly convoluted and I'm not sure I understand.
MessageCache is a cache of the MediaWiki namespace, a cache which is conceptually merged with various other message sources. Sometimes Language needs to access the MediaWiki namespace, and it does so via MessageCache. Language::getMessageFromDB is a helper function to facilitate such access. This is required to support important features such as per-wiki customisation of month names.
The way MessageCache supports multiple language objects is hackish, because the ability to support multiple language objects was added after MessageCache was designed, and it was never properly refactored.
I'm wondering, however, how this would be restructured if you had to chance to refactor this triumvirate of files without any regard to backwards-compatibility. Some questions:
- A global function is currently being used to do parameter
substitution: if you were to stuff this in a class, which class would go into?
MessageCache. Almost all of the wfMsg*() functionality should be in MessageCache.
- The message cache is currently used by extension authors to add their
own customizable messages to the mix. Is adding the messages straight to the cache the right thing to do, even if it is labeled mExtensionMessages? Would the cache be responsible for message retrieval? Should the class be renamed for sake of truthfulness?
Renamed to what?
- The cache is language aware in that it can accept messages for
specific languages but then figure out which one to use once based on $wgContLang or $wgLang (whichever is currently taking precedence).
It appears that MessageCache is not so much a cache but a loose confederation of tools for *getting* messages, performing some magic along with the global functions to figure out where to look, its own cache being only one of many places to look. Which is why I'm having trouble figuring this stuff out.
The object is named after the data it contains. The member functions are tools for operating on that data. We could call it MessageUtilities, but then it would sound like a mere collection of functions, and it would not be clear what happens when you instantiate, clone or serialize one of them.
-- Tim Starling
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tim Starling wrote:
MessageCache is a cache of the MediaWiki namespace, a cache which is conceptually merged with various other message sources. Sometimes Language needs to access the MediaWiki namespace, and it does so via MessageCache. Language::getMessageFromDB is a helper function to facilitate such access. This is required to support important features such as per-wiki customisation of month names.
Ah, when put in that context, that makes sense. Not such an ugly hack, then. (referring to the docblock on line 335 of Language.php)
The way MessageCache supports multiple language objects is hackish, because the ability to support multiple language objects was added after MessageCache was designed, and it was never properly refactored.
After refactoring, what would MessageCache look like? Would you have all the language objects cached in their own registry? This has a relationship to the key/lang syntax?
The object is named after the data it contains. The member functions are tools for operating on that data. We could call it MessageUtilities, but then it would sound like a mere collection of functions, and it would not be clear what happens when you instantiate, clone or serialize one of them.
In that context, the name makes sense. However, there are still quite a bit of methods that aren't really tied to that. What if you seperated the less related methods (get() stands out as one) into MessageUtilities, so that only methods directly manipulating the MediaWiki cache are in the MessageCache object. An extra file, yes, but possibly the difference between caching MediaWiki messages, and retrieving a message from multiple sources is sufficiently great enough to merit another include.
Edward Z. Yang wrote:
Tim Starling wrote:
MessageCache is a cache of the MediaWiki namespace, a cache which is conceptually merged with various other message sources. Sometimes Language needs to access the MediaWiki namespace, and it does so via MessageCache. Language::getMessageFromDB is a helper function to facilitate such access. This is required to support important features such as per-wiki customisation of month names.
Ah, when put in that context, that makes sense. Not such an ugly hack, then. (referring to the docblock on line 335 of Language.php)
The way MessageCache supports multiple language objects is hackish, because the ability to support multiple language objects was added after MessageCache was designed, and it was never properly refactored.
After refactoring, what would MessageCache look like?
MessageCache::get could accept a language code as input instead of a boolean for-content flag. That would avoid the ugly hack in Language::getMessageFromDB(), i.e. the comparison of the language code against the content and user languages.
Would you have all the language objects cached in their own registry?
That doesn't appear to be necessary, all the language data that MessageCache needs is available via the static member function Language::getMessagesFor().
This has a relationship to the key/lang syntax?
In part, yes.
The object is named after the data it contains. The member functions are tools for operating on that data. We could call it MessageUtilities, but then it would sound like a mere collection of functions, and it would not be clear what happens when you instantiate, clone or serialize one of them.
In that context, the name makes sense. However, there are still quite a bit of methods that aren't really tied to that. What if you seperated the less related methods (get() stands out as one) into MessageUtilities, so that only methods directly manipulating the MediaWiki cache are in the MessageCache object. An extra file, yes, but possibly the difference between caching MediaWiki messages, and retrieving a message from multiple sources is sufficiently great enough to merit another include.
I'm happy with it as it is.
-- Tim Starling
wikitech-l@lists.wikimedia.org