"Aryeh Gregor" <Simetrical+wikilist(a)gmail.com> wrote in message
news:p2n7c2a12e21004011306k9308cbfasb8aa0b688705ec93@mail.gmail.com...
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 <happy-melon(a)live.com> 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" <roan.kattouw(a)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. 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