On Sun, Mar 28, 2010 at 12:06 PM, Niklas Laxström
<niklas.laxstrom(a)gmail.com> wrote:
# $button = Xml::submitButton( Message::key(
'submit' )->text() );
# Message::key( 'welcome-to' )->params( $wgSitename )->parse();
# Message::key( 'bad-message' )->rawParams(
'<script>...</script>' )->escaped();
# Message::key( 'file-log' )->params( $user, $filename
)->inContentLanguage()->text();
It's great that we're trying to think of new ways to handle messages.
I like some of the aspects of the proposal, especially that it uses a
clear way of specifying the output format. However, I agree with some
of the others that there are issues with this that I'd like to see
worked out before we switch to it.
In particular, IMO, it's much more verbose than necessary. Verbosity
is okay if it adds clarity, but Message::key( 'welcome-to' )->params(
$wgSitename ) doesn't seem any clearer to me than Message::key(
'welcome-to', $wgSitename ), for instance. Also, Msg would be about
as intelligible as Message, but significantly easier to type (and it's
what we've used for ages until now anyway).
Actually, I think the current system is pretty good, except that the
variants are confusing for historical reasons. I'd stick fairly close
to the general syntax of what we have now. Off the top of my head, I
would suggest syntax like the following for the examples given:
# $button = Xml::submitButton( Message::key(
'submit' )->text() );
Msg::text( 'submit' );
# Message::key( 'welcome-to' )->params(
$wgSitename )->parse();
Msg::parse( 'welcome-to', $wgSitename );
# Message::key( 'bad-message' )->rawParams(
'<script>...</script>' )->escaped();
Msg::escaped( 'bad-message', array( 'raw-params' ),
'<script>...</script>' );
# Message::key( 'file-log' )->params(
$user, $filename )->inContentLanguage()->text();
Msg::text( 'file-log', array( 'content' ), $user, $filename );
This is where named formal parameters would be awesome, but if we're
not going to use arrays for the options, overloading would work -- an
array is options, a string is a parameter. (This means the usual
shortcut of allowing 'content' instead of array( 'content' ) would be
prohibited.)
This is kind of ugly, but options are only used in a fairly small
minority of cases (I think?), while parameters are used very often, so
I'd really like concise syntax for typical calls that just involve
message name, parameters, and output format. With __toString() we
could do
Msg::text( 'file-log', $user, $filename )->inContentLanguage()
or something, *without* adding extra syntax to the common case, but I
don't see a nice way to do this without __toString(). (I agree with
Werdna anyway that this feels weird and doesn't match how the rest of
MediaWiki works.)
An alternative to overloading would be having a separate version of
each method, like Msg::*Opts(), that accepted an extra options
parameter before the parameter parameters, but that seems uglier to
me.