On Thu, Apr 1, 2010 at 3:39 PM, Niklas Laxström <[email protected]> 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 <[email protected]> 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. _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
