I'm resurrecting this thread, because I really want to start using this new class. There are still open questions, like do we want to have a shortcut and how to name it. One reason for it is that name Message for a class might conflict and thus we might want to rename it to something else. My current preference would be i18n(), like this:
i18n( 'welcometo' $wgSitename)->text(); or if we don't have a wrapper, use this whatever the class name might be: Message::key( 'welcometo', $wgSitename )->text();
Other suggestions in the past have been: _ (Used by Gettext, objected because it's not clear what it does) _m (no comments)
I really don't believe that chaining method calls is too hard to use (or easy to misuse) for any of our developers. I recently noticed that FreeCol game (written in Java) uses chaining for message system very similar to this.
Yes, it is possible to use it in the wrong way, but I doubt that anyone is going to do that by accident, given the good documentation and plenty of correct examples. The few exception if any will be noticed easily in code review and fixed.
The other objection I still remember was about the inconsistent form of method names. If someone has suggestions for better naming scheme, please tell about us. I'd also like to know if anyone objects just because of that, even if they don't have suggestions for better names.
If you still object this change, please say it (again, if you have said something in past I've forgotten). If I get no objections I assume everyone can accept the new class.
Here's once more the reasons I want this system and how it is better than the old one: * Message objects make it easier to pass messages around * The most used case is simple and obvious, rare cases less so (but still not very hard) * It is easy to do the right thing * It actually works properly for i18n in the default cause (wfMsg doesn't) * If we in the future require PHP 5.3 or something, automatic string conversion can simplify the code even more * Rawness is now feature of individual parameter, not all of them - you can mix raw and nonraw now. * Usually shorter syntax, sometimes longer (depending on the shortcut we decide if any) * Usually more readable
And one other comment to old discussion:
On 4 April 2010 20:43, Happy-melon happy-melon@live.com wrote:
"Roan Kattouw" roan.kattouw@gmail.com wrote in message news:s2kf154f3a81004011326n7938f5b3i8d484f3d50f28fae@mail.gmail.com...
This'd be very nice, and would kind of supersede the Status class currently used to shove a message key and some params in so the callee can either get it automatically processed by wfMsg() (UI functions) or grab the raw message key + params and process that in their own way (API). This would require the Message class have getters for both of these though (does it currently?).
Roan Kattouw (Catrope)
As Roan says, a Message object essentially deprecates the (IMO pig-ugly) Status class, which is used erratically throughout the codebase as essentially a way to bundle up a message key, some parameters, and a success flag without converting to String too soon.
I don't think it replaces Status class, but just makes it a lot cleaner with regards to message handling. -- Niklas Laxström
On 08.07.2010, 13:02 Niklas wrote:
i18n( 'welcometo' $wgSitename)->text(); or if we don't have a wrapper, use this whatever the class name might be: Message::key( 'welcometo', $wgSitename )->text();
I don't like the function name 'key', it's unclear. Message::get() would be better imho.
Other suggestions in the past have been: _ (Used by Gettext, objected because it's not clear what it does) _m (no comments)
Message is fine. At most, we could rename it to Msg for those who are too lazy to type.
I really don't believe that chaining method calls is too hard to use (or easy to misuse) for any of our developers. I recently noticed that FreeCol game (written in Java) uses chaining for message system very similar to this.
Yes, it is possible to use it in the wrong way, but I doubt that anyone is going to do that by accident, given the good documentation and plenty of correct examples. The few exception if any will be noticed easily in code review and fixed.
Chaining could be surprizingly clear, albeit verbose. Much better anyway than the insanity we currently use: * wfMsg - mostly clear what it does * wfMsgNoTrans - ehm... * wfMsgForContent - what, what else do we use 'em for? Interface? Okay, I'll use wfMsgForInterface next time. * wfMsgForContentNoTrans - ouch, my eyes! * wfMsgNoDB * wfMsgNoDBForContent * wfMsgReal * wfMsgWeirdKey - omg * wfMsgHtml - probably clear what it does, but one'll have to guess some details * wfMsgWikiHtml - absolutely unclear * wfMsgExt - grrrrr
On Thu, Jul 8, 2010 at 6:14 AM, Max Semenik maxsem.wiki@gmail.com wrote:
Chaining could be surprizingly clear, albeit verbose. Much better anyway than the insanity we currently use:
- wfMsg - mostly clear what it does
Usually ;-)
- wfMsgNoTrans - ehm...
All of the *NoTrans mean "don't parse it."
- wfMsgForContent - what, what else do we use 'em for? Interface?
Okay, I'll use wfMsgForInterface next time.
No, we don't use it for interface elements (that's usually wfMsg()). It's used for things that end up *in* the content. Or stuff that gets heavily cached. "For content" means "in the content language"
- wfMsgForContentNoTrans - ouch, my eyes!
:)
- wfMsgNoDB
- wfMsgNoDBForContent
Self-explanatory.
- wfMsgReal
- wfMsgWeirdKey - omg
Both of these should become creepy internal methods for Message/Msg that should never be exposed to the public. You almost always don't need them.
- wfMsgHtml - probably clear what it does, but one'll have to guess
some details
I think this one is probably the most unclear to new developers.
- wfMsgWikiHtml - absolutely unclear
- wfMsgExt - grrrrr
The last one is my favorite because it's the most versatile. I would really hate to see its functionality disappear in a refactor.
(Just explaining all of these to people who might not know how they all work)
-Chad
On 8 July 2010 12:02, Niklas Laxström niklas.laxstrom@gmail.com wrote:
I'm resurrecting this thread, because I really want to start using this new class. There are still open questions, like do we want to have a shortcut and how to name it.
Hi again!
I'm proposing the following changes: * rename Message::key to Message::newFromKey * add global function wfMessage which is a shorter way to call Message::newFromKey
If you don't like this proposal, please suggest better names.
-Niklas
On 30.07.2010, 3:05 Niklas wrote:
- rename Message::key to Message::newFromKey
Overkillishly long.
- add global function wfMessage which is a shorter way to call
Message::newFromKey
Can't say I like it.
If you don't like this proposal, please suggest better names.
Message::get(), which I already mentioned.
On Fri, Jul 30, 2010 at 12:29 AM, Max Semenik maxsem.wiki@gmail.com wrote:
Message::get(), which I already mentioned.
Or, better yet, Msg::get(). wfMsg() is one of the most common functions in the codebase. Common functions need to be easier to write, because they're written more often; but can be harder to read, because you see them enough that you quickly remember what they do. The meaning of "Msg" is pretty easily guessable, too; I don't think anyone will assume it refers to monosodium glutamate.
On 7/30/10 8:35 AM, Aryeh Gregor wrote:
Msg::get(). wfMsg()
This seems like a minimum compromise. Personally I'd go all the way to M::get() or M(), but that would be a bit too obscure and would break existing conventions for Mediawiki source.
It's worth favoring brevity more than usual in the message string function. Since it's used so often, a short name tends to increase overall comprehensibility of the code.
Στις 30-07-2010, ημέρα Παρ, και ώρα 11:09 -0700, ο/η Neil Kandalgaonkar έγραψε:
On 7/30/10 8:35 AM, Aryeh Gregor wrote:
Msg::get(). wfMsg()
This seems like a minimum compromise. Personally I'd go all the way to M::get() or M(), but that would be a bit too obscure and would break existing conventions for Mediawiki source.
It's worth favoring brevity more than usual in the message string function. Since it's used so often, a short name tends to increase overall comprehensibility of the code.
I could live with the class name Msg instead of Message. "get" is not particularly descriptive. "wfMsgObj" is only three letters longer than the string we use now, if people think that "wfMessage" is too long to type.
Ariel
wikitech-l@lists.wikimedia.org