"Aryeh Gregor" <[email protected]> wrote in message news:[email protected]... >> That also means we can't do any >> cool stuff because there wont by any Message objects. With objects >> functions can see that they are getting a message instead of just any >> random string. > > What are some good uses of this that won't magically work for some > methods but fail in 95% of the others, so that you have to memorize > which exact methods support Message parameters and which don't? And > that also won't require adding boilerplate Message-handling code to > hundreds of methods? > >> There is also many places in the code where messages >> are passed to functions. We could pass Message objects there instead >> of array( 'key', 'param', 'param' ), which is quite inflexible. > > Where are some examples of this, and some sample benefits? > > On Thu, Apr 1, 2010 at 3:59 PM, Happy-melon <[email protected]> wrote: >> I think the existence of a Message object that can be instantiated and >> passed around, is a very important benefit. As you say, if we go down >> the >> other route, we just end up with the wfMsg functions in a different >> namespace. > > We'd end up with *cleaned-up* wfMsg() functions in a different > namespace. That's the only benefit I see as compelling, that they be > clean and easy to use. I have no problem with the general approach > taken by wfMsg*(), they've just become rather crufty and confusing > over the years. Compare Linker::link() to all the methods it > replaced. It's not fundamentally different, it's just cleaner and > easier to understand. > > I don't see a lot we can do with objects without adding excessive > clutter, given PHP's deficiencies. In almost all cases you really do > just want plain old strings, and requiring extra method calls > everywhere for the sake of uncommon cases is uneconomical. > > Of course, once we require a version of PHP that supports > __toString(), we could transparently alter all existing > message-related functions (including wfMsg() and friends) to return > some Message object with a __toString() method. That would give us > the best of all worlds. Until then, if you really wanted objects you > could create them for whatever uses you have for them, but the vast > majority of callers don't need any kind of object and would really > just like a string.
"Roan Kattouw" <[email protected]> wrote in message news:[email protected]... > > 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. Status has always struck me as an unpleasant implementation: processes should throw exceptions on fatal errors, return messages on non-catastrophic problems, and bool true on success. Even more erratic is the way we have functions returning message keys, or maybe array('key','param','param'), or maybe array('key',array('param','param')), or maybe something even more exotic. Cf r63678; somewhere in that stack a String is appearing when it's "supposed" to be an array, but when nested arrays anywhere between 0 and 2 layers deep are valid input, it's not altogether surprising. Having an array of Message objects on which you can call array_udiff() and array_uintersect() with a static method Message::equals() (even PHP's native implementation of Object == Object is ok), will make that process reasonably sane. And "that process" is what you get every time User::getPermissionsErrors() is invoked. --HM _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
