On 1 April 2010 21:33, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
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).
Message::key( 'welcome-to', $wgSitename ) works already. Renaming the class is easy and I don't mind if it is Message or Msg.
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:
I don't think the current system is good. Details below:
# $button = Xml::submitButton( Message::key( 'submit' )->text() );
Msg::text( 'submit' );
If Xml::submitButton() would be intelligent, it could just be Xml::submitButton( Msg::key( 'submit' ) ); This is related to the pain that is Xml::element( 'foo', array() wfMsgExt( 'bar', 'escapenoentities' ) );
# Message::key( 'welcome-to' )->params( $wgSitename )->parse();
Msg::parse( 'welcome-to', $wgSitename );
All is fine until...
# Message::key( 'bad-message' )->rawParams( '<script>...</script>' )->escaped();
Msg::escaped( 'bad-message', array( 'raw-params' ), '<script>...</script>' );
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.
# 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.)
The other things I don't like flat array of options that do different unrelated things. I also don't like they perhaps worst ever array syntax for lists in PHP. 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'm not really sure *what* are the issues in current proposal that people want fixed. I've just seen dozens of suggestions to do something very different. I guess they could be: * Syntax is too verbose -- Suggested: Msg instead of Message -- Implemented: allow ::key( 'key', $param1, $param2... ) * 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 -- IMO, the risk is very low that someone needs to do something special and get it wrong too * Naming of the functions is not consistent -- Open to suggestions here
Things that seem to be ok: * Thy syntax is readable * It has all the features that were initially specified
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? 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. 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.
What do others think of the above?
-Niklas