On Sun, Mar 28, 2010 at 12:06 PM, Niklas Laxström niklas.laxstrom@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.