On 1 April 2010 21:33, Aryeh Gregor <Simetrical+wikilist(a)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
--
Niklas Laxström