On Thu, Apr 1, 2010 at 3:39 PM, Niklas Laxström
<niklas.laxstrom(a)gmail.com> wrote:
If Xml::submitButton() would be intelligent, it could
just be
Xml::submitButton( Msg::key( 'submit' ) );
That would automatically HTML-escape it? That would be nice, but
you'd have to modify an awful lot of functions for that to work
reliably enough to not seem like voodoo magic. What would be much
awesomer is if we could use __toString() and make that default to
HTML-escaping.
Bang! That would break one thing we was trying to fix.
"rawness"
should be per param, not per message. There is Message::rawParam() to
wrap those, but I don't like it as much as chaining.
I like it more than chaining. :) Chaining looks weird, IMO. And
that *is* a valid criticism as long as we're debating aesthetics,
although I understand that it's probably frustrating.
The other things I don't like flat array of
options that do different
unrelated things.
How is that different from a flat chain of method calls that do
different unrelated things?
I also don't like they perhaps worst ever array
syntax for lists in PHP.
Seems simpler to me than chaining, nonetheless.
I don't really like that we just stuff all
the stuff in one function call and do with some magic with them
either.
I prefer that style. It's certainly what we tend to use elsewhere in
MediaWiki, and PHP encourages it.
* Chaining is confusing/different from everything
else
-- Class has good documentation
* Chaining can be used in a way that may cause unexpected behaviour
-- Class has good documentation
Good documentation is not a substitute for behaving as expected. It
should behave consistently with other functions *and* also have good
documentation.
If we just replace ::key() with ::format() and tack
options somewhere
in the params, we just have new set of wfMsg* functions, just with
better names. Is that what we want?
I have no problem with that.
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.