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