Hey,
Proposed:
$tp = new TextTitleParser(); try { $title = $tp->parse( $text ); $tf = new UrlTitleFormatter( $title, 'foo=bar ); return $tf->format(); } catch( MWException ) { return null; }
I hope this is your own interpretation of what would happen on top of what is proposed and not what is actually proposed, since this code snippet has some issues.
Those parser and Formatter objects contain configuration specific state. If you instantiate them like this, you are creating code that is just as bad as Title::newFromText, where this newFromText method relies on similar config specific state. In both cases you are using global state and programming against concretions.
Does the RFC also sate exceptions should be used rather than returned error values? Seems like a quite disjoint concern to me. And if you use exceptions, please use them properly and do not copy-paste MWException all over.
This example also seems rather fabricated and not representative of most use cases. Ignoring the points above, it strikes me as only making sense in a transaction script, ie something which goes from handling user input (such as parsing a title), through domain logic (altering a title), to presentation (ie formatting a title). Given what MW does, it is much more likely any particular piece of code only resides in one layer, rather then 3. Though I can imagine how we have lots of code that for no good reason does this anyway, quite plausibly prompted by the fact that the Title object caters to all 3 layers.
I read that as namespaces other than the one you're obviously referring
to with a TitleValue--so Category:Foo only knows about Category:, not Project: or User:.
Maybe someone can clarify here?
It is good to have a value object to not be dependent on configuration, so instances of it do not get messed up if the config is changed. So presumably in this case it'd contain an int, rather then an internationalized sting or whatever.
Also,
http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html
I stopped reading at
All Java people love "use cases"
Perhaps you could summarize what the RFC in question does wrong according to the post you linked?
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 --