Am 30.10.2013 18:32, schrieb Martijn Hoekstra:
Rebase early, rebase often. At some point integration must take place. Not
using a separate branch won't help you there. Anyone working on anything
involving the title object that hasn't been merged yet will hate to rebase
whenever you'll have
Am 31.10.2013 14:52, schrieb Daniel Kinzler:
The idea is to *not* actually refactor the Title class, but to introduce a
light
weight alternative, TitleValue. We can then replace usage of Title with usage
of
TitleObject bit by bit.
That was meant to be replace Title with TitleValue, of
Am 10.10.2013 18:40, schrieb Rob Lanphier:
Hi folks,
I think Daniel buried the lede here (see his mail below), so I'm
mailing this out with a subject line that will hopefully provoke more
discussion. :-)
Thanks for bumping this, Rob. And thanks to Tim for moderating this discussion
so far,
On Oct 30, 2013 3:11 PM, Daniel Kinzler dan...@brightbyte.de wrote:
Am 10.10.2013 18:40, schrieb Rob Lanphier:
Hi folks,
I think Daniel buried the lede here (see his mail below), so I'm
mailing this out with a subject line that will hopefully provoke more
discussion. :-)
Thanks for
On 25/10/13 03:32, Daniel Friesen wrote:
On 2013-10-24 9:19 AM, Brad Jorsch (Anomie) wrote:
The claimed problem behind a lot of this is too many dependencies
making things hard to test and the idea that you can somehow make this
go away by dividing everything into tinier and tinier pieces. To
Le 25/10/13 07:55, Tim Starling a écrit :
Since the Title class is large to start with (4895 lines) I figure it
can tolerate being cut up a few times without the resulting pieces
becoming tiny. So, it makes an interesting test case for the approach.
We will see the consequences with more
On 24.10.2013, 6:54 Chad wrote:
On Wed, Oct 23, 2013 at 7:39 PM, Tim Starling tstarl...@wikimedia.orgwrote:
I'm inclined to accept this RFC, except perhaps with minor changes. It
would be nice if I could get some comments on it from someone other
than me or Daniel, but if nobody else has
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
Le 24/10/13 11:40, Max Semenik a écrit :
Now:
$title = Title::newFromText( $text );
if ( $title ) {
return $title-getLocalUrl( 'foo=bar' );
}
return null;
Proposed:
$tp = new TextTitleParser();
try {
$title = $tp-parse( $text );
$tf = new UrlTitleFormatter( $title,
On Thu, Oct 24, 2013 at 12:04 AM, Chad innocentkil...@gmail.com wrote:
On Wed, Oct 23, 2013 at 8:44 PM, Tyler Romeo tylerro...@gmail.com wrote:
On Wed, Oct 23, 2013 at 10:54 PM, Chad innocentkil...@gmail.com wrote:
I've personally not been convinced of this Value/Parser/Formatter
On 2013-10-24 9:19 AM, Brad Jorsch (Anomie) wrote:
The claimed problem behind a lot of this is too many dependencies
making things hard to test and the idea that you can somehow make this
go away by dividing everything into tinier and tinier pieces. To some
extent this works, but at the cost
On 24/10/13 23:19, Jeroen De Dauw wrote:
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
On 25/10/13 03:19, Brad Jorsch (Anomie) wrote:
So then the RFC proposes a ServiceRegistry to try to get around this
problem of everything requiring dozens of arguments. But after observing
that RequestContext already *is* this, it then argues against using
RequestContext on the basis of
I'm inclined to accept this RFC, except perhaps with minor changes. It
would be nice if I could get some comments on it from someone other
than me or Daniel, but if nobody else has anything to say, I will just
accept it.
-- Tim Starling
On 11/10/13 03:40, Rob Lanphier wrote:
Hi folks,
I
On Wed, Oct 23, 2013 at 7:39 PM, Tim Starling tstarl...@wikimedia.orgwrote:
I'm inclined to accept this RFC, except perhaps with minor changes. It
would be nice if I could get some comments on it from someone other
than me or Daniel, but if nobody else has anything to say, I will just
accept
On Wed, Oct 23, 2013 at 10:54 PM, Chad innocentkil...@gmail.com wrote:
I've personally not been convinced of this Value/Parser/Formatter pattern
but if I'm the only one I'll just keep my big mouth shut
I agree with this as well. The idea behind this RFC is the hair can't cut
itself pattern.
On Wed, Oct 23, 2013 at 8:44 PM, Tyler Romeo tylerro...@gmail.com wrote:
On Wed, Oct 23, 2013 at 10:54 PM, Chad innocentkil...@gmail.com wrote:
I've personally not been convinced of this Value/Parser/Formatter pattern
but if I'm the only one I'll just keep my big mouth shut
I agree with
On Thu, Oct 24, 2013 at 12:04 AM, Chad innocentkil...@gmail.com wrote:
I would assume something like the prefixed text form. As long
as the TitleValue knows its namespace and title you can guess
the rest.
Maybe, but the RFC says, As a value object, this has no knowledge about
namespaces,
On Wed, Oct 23, 2013 at 9:25 PM, Tyler Romeo tylerro...@gmail.com wrote:
On Thu, Oct 24, 2013 at 12:04 AM, Chad innocentkil...@gmail.com wrote:
I would assume something like the prefixed text form. As long
as the TitleValue knows its namespace and title you can guess
the rest.
Maybe,
On 2013-10-23 9:39 PM, Chad wrote:
On Wed, Oct 23, 2013 at 9:25 PM, Tyler Romeo tylerro...@gmail.com wrote:
On Thu, Oct 24, 2013 at 12:04 AM, Chad innocentkil...@gmail.com wrote:
I would assume something like the prefixed text form. As long
as the TitleValue knows its namespace and title you
Hi folks,
I think Daniel buried the lede here (see his mail below), so I'm
mailing this out with a subject line that will hopefully provoke more
discussion. :-)
This is an RFC we originally conceived at the Hong Kong Wikimania
architecture discussion. The notes from that are here:
21 matches
Mail list logo
