Wishlist thread

[sri]

Happy new year everyone!

2013 has been a great year for Mojolicious and we've made a lot of progress, lets start 2014 by trying something new.

In this thread you can post changes or features you would like to see in Mojolicious, no rules, just blurt away. :)

P.S.: Our official roadmap can be found on GitHub. https://github.com/kraih/mojo/issues?labels=future&state=open

--

sebastian

[Виктор Турский]

I would like to use the Test::Mojo module for external APIs (sites) testing.

Something like this:

my $t = Test::Mojo−>new( path => 'http://example.com/api/v3' );

$t−>post_ok('/search.json' => form => {q => 'Perl'}) ... .

this should send the data to http://example.com/api/v3/search.json

--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious...@googlegroups.com.
To post to this group, send email to mojol...@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/groups/opt_out.

--
Viktor Turskyi
http://webbylab.com
http://koorchik.blogspot.com

[Brian Duggan]

On Thursday, January 2, sri wrote:
> Happy new year everyone!
>
> 2013 has been a great year for Mojolicious and we've made a lot of
> progress, lets start 2014 by trying something new.
> In this thread you can post changes or features you would like to see in
> Mojolicious, no rules, just blurt away. :)

Happy new year, all.

My new year's wish would be to see Mojo::UserAgent resend more headers
during redirects by default. Some discussion is at <https://github.com/kraih/mojo/pull/525>.

A motivating use case is being able to substitute "mojo get -r -H"
for "curl -LH" in the examples on <http://crosscite.org/cn/>.

Brian

[Scott Wiersdorf]

I'd like to see a nice scalable, event-driven, non-blocking programming style from Mojolicious. I've been down a long road, building a moderately large blocking Mojo app, converting it to a non-blocking app using continuation-passing style (callbacks--very messy). Now we're planning on converting the app into a pure event-driven style using Mojo::IOLoop and friends, but there are few good patterns to follow for doing this at scale, so we're making things up as we go. It's also a major rewrite because blocking style does not easily lend itself to this.

Mojolicious is such an elegant and clean framework, it has a chance to define or at least be at the forefront of what it means to write scalable, event-driven apps for any programming language. For example, the recentish 'continue()' method was a huge help. More development along these lines would be awesome.

Scott

[Scott Wiersdorf]

I'd also like to see Mojo::JSON be able to fall back to JSON::XS if it's already installed. One of my apps spends a good percentage of its time serializing and deserializing JSON (according to Devel::NYTProf). When I swapped out Mojo's serializer for JSON::XS, the difference was significant.

[Scott Wiersdorf]

While we're at it... :)

Having Test::Mojo have a json_like() method would be helpful. I find myself doing this a lot to test a scalar value at a JSON path:

    $res = $t->get_ok(...)->tx->res;

    like( $res->json('/foo/bar'), qr(baz), "baz found" );

rather than:

    $t->get_ok(...)->json_like('/foo/bar' => qr(baz));

[Ben van Staveren]

^ this, I'm busy jumping similar hurdles and could benefit from it as
well :D

[sri]

> Mojolicious is such an elegant and clean framework, it has a chance to
> define or at least be at the forefront of what it means to write scalable,
> event-driven apps for any programming language. For example, the recentish
> 'continue()' method was a huge help. More development along these lines
> would be awesome.
>
> Scott
>
^ this, I'm busy jumping similar hurdles and could benefit from it as
well :D

You two got anything specific in mind you could elaborate on?

--

sebastian 

[sri]

It's also a major rewrite because blocking style does not easily lend itself to this.

Personally, i would like to explore coroutine/generator based APIs more, but that's not really an option for anything serious as long as Coro is the only game in town.

    https://gist.github.com/kraih/6082061

--

sebastian

[Ben van Staveren]

On 01/02/2014 10:07 PM, sri wrote:
>
>
> You two got anything specific in mind you could elaborate on?
>
> --
> sebastian
>

Well, my main thing is that I've got issues with bridges and waypoints,
for example I use a bridge to see if a user is authenticated and if they
are, it pulls up a wad of information from MongoDB using Mango - the
only issue I have is that a bridge must return a value to indicate
whether the rest of the chain needs to be handled. Either I do it wrong,
or I can't seem to find away to do this in a non-blocking manner, e.g.
if I'm in a Mango find_one callback, I can't say "return 1" and have
that be the return value for the bridge.

Right now I kludge it together with the around_action hook but I doubt
that's what it was meant for, at least, it seems to be a rather
sledgehammer-ish solution. I'd love to see a bridge_nb where I'd be able
to do stuff like:

sub bridge {
my $self = shift;
my $next = shift;

$self->model('foo.bar')->find_one({ ... } => sub {
my ($coll, $err, $doc) = (@_);

if($doc->{foo}) {
$next->continue;
} else {
$next->stop;
}
});
}

Like I said, maybe it's possible already, I couldn't figure it out so I
may be talking up the wrong tree here :D

Basically a way to explicitly request that the dispatcher lets bridges,
waypoints, and other such things do it's thing in this fashion would let
me deal with it in a nicer way than messing with around_action or even
around_dispatch since it just feels too brutal for something like this.

[Ben van Staveren]

Would be the bee's knees (or the dog's bollocks) to have something like
that, but Coro gives me the willies...

[Sebastian Riedel]

...waypoints...

Those don't exist anymore since 3.0 or so.

 

    if($doc->{foo}) {
      $next->continue;
   } else {
      $next->stop;
   }

Already exists, and was actually mentioned by Scott above. :)

    http://mojolicio.us/perldoc/Mojolicious/Guides/Routing#Bridges 

--

Sebastian Riedel

http://mojolicio.us

http://github.com/kraih

http://twitter.com/kraih

[Ben van Staveren]

On 01/02/2014 10:48 PM, Sebastian Riedel wrote:
>> ...waypoints...
>>
> Those don't exist anymore since 3.0 or so.
>
>
>> if($doc->{foo}) {
>> $next->continue;
>> } else {
>> $next->stop;
>> }
>
> Already exists, and was actually mentioned by Scott above. :)
>
> http://mojolicio.us/perldoc/Mojolicious/Guides/Routing#Bridges
>

>.>

See I should really bloody well read the docs for new releases, my bad!

[sri]

I would like to use the Test::Mojo module for external APIs (sites) testing.

Something like this:

my $t = Test::Mojo−>new( path => 'http://example.com/api/v3' );

$t−>post_ok('/search.json' => form => {q => 'Perl'}) ... .

Already works.

    my $t = Test::Mojo->new;

    $t->post_ok('http://example.com/api/v3/search.json' => form => {q => 'Perl'})...

--

sebastian

[Joe Landman]

A few things on the wishlist:

1) Long standing (but minor) annoyance I'd love to see addressed.

All the Mojo* scripts seem to use '/usr/bin/env perl' in their header.
This is true regardless of which perl we use to build them. As we have
our own out-of-distro perl we use for our apps, residing in its own
tree, I have to manually change every instance of this in all the
mojolicious/mango/... code to point back to our perl.

Setting a path environment is a non-starter ... a really good way to
break a distribution is to replace their core bits with the bits you
need. Getting the distribution to fix their perl, and use something
which hasn't been EOL for 3+ years is well ... its CentOS, which is
built off of Red Hat, whom think 5.10.x is shiny and new.

Basically, it would save us time at each new Mojo* update if the
build/make code picked up the path of the perl binary used to build it.
FWIW, I'd be happy to contribute patch(es) to this effort if this is
something you'd consider.


2) This is going to sound strange/too-simple/...

I'd love there to be a very basic framework/scaffold of an application
(::Lite is fine/preferred) that has authentication built up correctly.

Why this is important to me: I look at authentication as boilerplate
stuff that I don't want to write. I want something that just works (not
unlike Mojo*), that I can build upon.

Yeah, I know the counter arguments: every login system is different,
everything for logins should be custom.

But I think there is enough commonality that a simple pattern could be
supplied. Basically I look at Mojo* as a best practice system we build
our apps upon, and I'd like to leverage best practice login technologies
without having to go through the joy of coding our own (and finding bugs
to fix, etc.) as compared to spending time on the app itself.

This might be better addressed with a Mojolicious::Plugin::Login thing,
and I'm even happy to take a stab at starting this.


3) More important: SSL docs/examples ... Maybe I missed this, but I'd
like it to be more prominent. I tend to front the Mojo apps on the
interwebs with nginx, but for our internal (not exposed to the evil
interwebs) apps, I still want SSL if at all possible.

[sri]

All the Mojo* scripts seem to use '/usr/bin/env perl' in their header.

...

Basically, it would save us time at each new Mojo* update if the
build/make code picked up the path of the perl binary used to build it.
   FWIW, I'd be happy to contribute patch(es) to this effort if this is
something you'd consider.

This needs to be fixed in ExtUtils::MM and is out of our hands now.

    https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/issues/58

--

sebastian

[sri]

    $res = $t->get_ok(...)->tx->res;

    like( $res->json('/foo/bar'), qr(baz), "baz found" );

rather than:

    $t->get_ok(...)->json_like('/foo/bar' => qr(baz));

I'm on the edge about this, i can see it being useful but the inconsistency with the "is_deeply()" based json_is() (and json_message_is()) bugs me.

--

sebastian

[Ben van Staveren]

There's Mojolicious::Plugin::Authentication as well :)

[Joe Landman]

On 01/02/2014 12:36 PM, Ben van Staveren wrote:

>> This might be better addressed with a Mojolicious::Plugin::Login
>> thing, and I'm even happy to take a stab at starting this.
>
> There's Mojolicious::Plugin::Authentication as well :)

Thats part of it ... I mean more of a plugin where you hand it a set of
pages for login, request an account, failed, etc... .

Basically I am looking for something that would use M::P::A as part of
it, but make that whole process much simpler. I know about how to write
good logic for my apps, I don't want to have to worry about whether my
login workflow is correct ...

I know it might seem trivial, but if you think about it, a good/correct
login process flow is an important part of security. If you code
something incorrectly, you can wind up letting the evil interwebs at
your precious data ... something I'd like to avoid. Its not that I
can't hack through this myself, its that there are some best practices
for this.

Something akin to MojoX::Auth::Simple
(http://search.cpan.org/~kimhawtin/MojoX-Auth-Simple-0.04.03/lib/MojoX/Auth/Simple.pm),
but as a core part of the system. Convos::User shows part of what I am
thinking of.

[Joel Berger]

Of course we would all like to see the continuation style, but in the meantime, have you investigated Mojo::IOLoop::Delay. It does help in detangling the callback mess. I have written some blog posts about it (and have been meaning to post a few more, bad Joel!) at http://blogs.perl.org/users/joel_berger/2013/10/writing-non-blocking-applications-with-mojolicious-part-1.html and http://blogs.perl.org/users/joel_berger/2013/11/writing-non-blocking-applications-with-mojolicious-part-2.html

[Stefan Adams]

On Thu, Jan 2, 2014 at 11:49 AM, Joe Landman <joe.l...@gmail.com> wrote:

There's Mojolicious::Plugin::Authentication as well :)

Thats part of it ... I mean more of a plugin where you hand it a set of pages for login, request an account, failed, etc... .

Basically I am looking for something that would use M::P::A as part of it, but make that whole process much simpler.  I know about how to write good logic for my apps, I don't want to have to worry about whether my login workflow is correct ...

I know it might seem trivial, but if you think about it, a good/correct login process flow is an important part of security.  If you code something incorrectly, you can wind up letting the evil interwebs at your precious data ... something I'd like to avoid.  Its not that I can't hack through this myself, its that there are some best practices for this.

Something akin to MojoX::Auth::Simple (http://search.cpan.org/~kimhawtin/MojoX-Auth-Simple-0.04.03/lib/MojoX/Auth/Simple.pm), but as a core part of the system.  Convos::User shows part of what I am thinking of.

My thought, similar to Joe, I think, is that the Mojo built-in Login would be a best practices method (like with CSRF and Validation) that grants security, at least from a prototyping perspective.  Let someone develop an app without all the repetition of something so crucial, let it get big, and then let the developer swap out the Login to something more powerful.  But at least the developer didn't have to start the prototyping phase with the annoying repetition of all of the steps of initializing Login.

For example, have Mojo include the basic conditions, routes, and helpers that require the developer to simply dig right in and use them.

use Mojolicious::Lite;

get '/' => (auth => qr/%group|user/) => 'index';

app->start;

And the authentication would be tied to a simple htpasswd style text file or something that could define users and passwords and have users in groups and groups in groups.

[sri]

My thought, similar to Joe, I think, is that the Mojo built-in Login would be a best practices method (like with CSRF and Validation) that grants security, at least from a prototyping perspective.

I doubt there would be consensus on how exactly something like that should look like.

--

sebastian 

[Stefan Adams]

On Thu, Jan 2, 2014 at 9:47 PM, sri <kra...@googlemail.com> wrote:

My thought, similar to Joe, I think, is that the Mojo built-in Login would be a best practices method (like with CSRF and Validation) that grants security, at least from a prototyping perspective.

I doubt there would be consensus on how exactly something like that should look like.

Let's say there could be.  Would that be sufficient to approve?  Could the feature be broken down to the bare minimum of simplicity to just merely offer an introductory implementation?

[sri]

Let's say there could be.  Would that be sufficient to approve?

I'm not opposed to the feature, if that's what you mean, but of course it has to go through the usual approval process.

--

sebastian

[sri]

    $t->get_ok(...)->json_like('/foo/bar' => qr(baz));

I'm on the edge about this, i can see it being useful but the inconsistency with the "is_deeply()" based json_is() (and json_message_is()) bugs me.

Discussing this feature on IRC had some interesting results, we are going to try encouraging a different kind of extension for Test::Mojo and possibly a few other classes. :)

    https://github.com/kraih/mojo/compare/c56a12ad774d585a2d035aa50996d718933e5da1...75df849d184dbd64712e5e8bfa54524b7c1df85a#diff-a3cb567ecd4d756d754d1baee62ee931R419

This is just a first step though, Joel is working on a more complete cookbook recipe.

--

sebastian

[Scott Wiersdorf]

On Thursday, January 2, 2014 8:07:06 AM UTC-7, sri wrote:

You two got anything specific in mind you could elaborate on?

The Mojolicious::Lite tutorial is one of the finest introductions of any framework I've used. It spells out the Mojolicious-style of doing things. It has the most common situations you'll come across when writing a web app, and then Mojolicious::Controller has everything else, also well documented.

There are also ample examples (ex-amples?) of what I would call "toy" guides for non-blocking, including Joel's recent (and excellent) tutorials. But *all* of them demonstrate only the technical aspect of making a non-blocking call. What I'd like to see--and would be happy to help with, but which I'm likely unsuited for because I'm asking for it--is a guide that explains how to write a largeish scale application in the non-blocking style with Mojo::IOLoop::Delay. For example, an app that acts as a proxy/aggregator for several other web services (that would give reasonable justification for the approach): this application has multiple helpers or plugins that handle making connections (via Mojo::UserAgent) to other services and how those would be used in our controllers, etc.

I'm not sure I'm being very clear, but the thrust of my suggestion is: I know how to build a web application in Mojolicious thanks to M::L's tutorial. I have no idea how to convert that same app into a non-blocking version--I doubt there is a nice path. So, assuming there is no clean path, how should I have begun in the first place using Mojo::IOLoop::Delay? It seems there are two distinct and incompatible ways to build a web app: blocking and non-blocking, with the former extremely well-documented and the latter only documented in functions and toy uses.

Scott

[sri]

So, assuming there is no clean path, how should I have begun in the first place using Mojo::IOLoop::Delay? It seems there are two distinct and incompatible ways to build a web app: blocking and non-blocking, with the former extremely well-documented and the latter only documented in functions and toy uses.

Don't think it can be done, since there are no established best practices for non-blocking web apps in Perl (and/or Mojolicious) yet, we are still in the trial and error phase.

Good example for this is the "continue" feature we added just a few weeks ago, and which you mentioned yourself earlier in this thread.

--

sebastian

[Scott Wiersdorf]

Yeah, I was afraid of that :)

Ok, well, I'll be off with a few other brave souls trying to forge some better practices for non-blocking web apps! Wish us luck. If anyone out there gets into a situation where they need to write a large, non-blocking web app (but not using callbacks/continuation-passing style) and feels like they've made some good progress in setting up routes and writing the controllers for such a beast, please share!

Scott

[sri]

...please share!

I think the best we have at the moment is Convos.

    http://blog.kraih.com/post/69783934209/convos-chatting-in-the-cloud-with-mojolicious

--

sebastian 

[Stefan Adams]

Is there a way for Mojo::IOLoop->recurring($interval => sub { ... }); to run NOW as well as every $interval seconds?  If not, does it make sense to build in an option that would allow it to work like that?

What's the way that people are doing that now?

my $sub = sub { ... };

Mojo::IOLoop->timer(0 => \&sub);

Mojo::IOLoop->recurring($interval => \&sub);

Is there a more concise means to accomplishing that?  If not, could there be?

On Wed, Jan 1, 2014 at 11:59 PM, sri <kra...@googlemail.com> wrote:

Happy new year everyone!

2013 has been a great year for Mojolicious and we've made a lot of progress, lets start 2014 by trying something new.

In this thread you can post changes or features you would like to see in Mojolicious, no rules, just blurt away. :)

P.S.: Our official roadmap can be found on GitHub. https://github.com/kraih/mojo/issues?labels=future&state=open

--

sebastian

[sri]

Is there a more concise means to accomplishing that?  If not, could there be?

 

Please do not abuse this thread for general questions by attaching a "If not, could there be?" to the end.

--

sebastian

[Valuyskiy Alex]

I want to have "before_render" hook.

[sri]

I want to have "before_render" hook.

Why? We generally don't add new hooks unless they have at least two independent use cases, to ensure they are generic enough.

--

sebastian 

[Valuyskiy Alex]

1) I need to execute some parts of code right after controller's action. For example, I'm prepairing one part of my layout only after controller's actions, because I need to update "message counters" text after controller updates it in DB. I can put these code into template, but it very bad variant. I need something like after_controller/before_render hook.

2) I need to execute some part of my layout code only for specific formats (only for HTML). That why I need some hook, where I can use $self->stash('format'). So, or something after_routes/before_controller or after_controller/before_render.

3) I want to use mobile version of template if it exists. But I don't like to write boilerplate code in each action, like $self->render_maybe('blog/list.mobile') or $self->render('blog/list');

среда, 8 января 2014 г., 16:47:32 UTC+2 пользователь sri написал:

[Sebastian Riedel]

1) ... 2) ... 3) ...

That's all one use case really, and i'm not even sure it's a valid one. If someone else has an opinion on this i'd like to hear it.

[Ben van Staveren]

On 01/08/2014 10:54 PM, Sebastian Riedel wrote:
>> 1) ... 2) ... 3) ...
>>
> That's all one use case really, and i'm not even sure it's a valid one. If
> someone else has an opinion on this i'd like to hear it.
>

I think I had that before_render hook idea a long, long time ago and I
think it even was part of Mojolicious for about 2 releases before it was
removed again. On the use case described though, you could just as well
have the logic inside your action, then use $self->render_partial to
render the bits you need, and finally pass all that off to one template
that basically includes the rest - or just concatenate it into
$self->res->body. I think currently my only use case for a before_render
hook is to have a chance to get some timing values before the render
phase starts.

Just my 2 cents, I'm ambivalent on whether or not it's added :)

[sri]

 ...then use $self->render_partial to
render the bits you need...

That reminds me of one of the biggest problems the before_render hook had... recursion whenever someone tried to render inside the hook.

Don't laugh, that was a common complaint.

--

sebastian 

[Disaster123]

I have two wishes.

1.) app wide exception and not found templates / messages especially useful for json apps

2.) I would like to see mojo using JSON::XS automagically if installed. Pure perl json is awfully slow and coasts a lot of CPU.

Thanks!

[sri]

1.) app wide exception and not found templates / messages especially useful for json apps

Any concrete proposals?

--

sebastian 

[Disaster123]

1.) app wide exception and not found templates / messages especially useful for json apps

Any concrete proposals?

May be in the application?

sub startup {

...

}

sub render_exception

sub render_not_found

or something like

 my $r = $self->routes();

 $r->set_render_not_found(\&mysub);

 $r->set_render_exception(\&mysub);

 my $json = $r->get('/json')->to('json#abc');

 $json->set_render_not_found(\&mysub_json);

 $json->set_render_exception(\&mysub_json);

Stefan 

[sri]

sub render_exception

sub render_not_found

...

 $r->set_render_not_found(\&mysub);

 $r->set_render_exception(\&mysub);

I'm afraid that doesn't really tell me much, actual semantics and deprecation paths for current behavior would be much more helpful.

Perhaps even a partial patch.

--

sebastian

[Adam McLean]

+1 to optionally offloading JSON work to a faster module.  I use Mojo extensively as a RESTful backend between servers, and when we get into multi-MB of JSON in a single request I often get a 100% CPU Perl process for a few minutes while it works through it all.

No preference which module.  I'd be fine if there was an optional Mojo::JSON::C that was compiled at installation for those who chose to do so.  That would assure consistency in test cases and existing encode/decode assumptions.

Thanks!

[sri]

I'd be fine if there was an optional Mojo::JSON::C that was compiled at installation for those who chose to do so.

This is not going to happen in core, but i don't see a reason why there can't be a Mojo::JSON::XS module on CPAN that works similar to Mojo::Base::XS.

    https://metacpan.org/pod/Mojo::Base::XS

--

sebastian

[sri]

This is not going to happen in core, but i don't see a reason why there can't be a Mojo::JSON::XS module on CPAN that works similar to Mojo::Base::XS.

I have to admit that i'm a little disappointed that this has not happened yet, there have been 3 requests in this thread alone.

Wonder if there are ways for us to get the community more engaged. Is there anything specific that keeps you from contributing?

--

sebastian 

[Ben van Staveren]

A hideous lack of enough free time to write the code and be around to
actually support it, $bill_paying_job puts a decent dent in my available
time, and my munchkin tends to eat up whatever's left. For me it's more
a case of I want to, if only I had the time to :)

[David Oswald]

I'd be happy to work on it. Give me a few days to assemble the time.  If someone beats me to it, so be it. But I should be able to get started in the next day or two... shouldn't be too big of a job.  If I recall, though, JSON::XS isn't going to pass the Mojo::JSON tests, so we might have to accept a few discrepancies, documented of course.

--

[Adam McLean]

I'll contribute any way I can. I don't think I could produce Mojo quality code but I'm happy to help test, document and support it.

You received this message because you are subscribed to a topic in the Google Groups "Mojolicious" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mojolicious/YK7SrFvEneY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mojolicious...@googlegroups.com.

[Ben van Staveren]

Just so we're not mucking up the wishlist but... in startup if you do
this, you get JSON::XS encoding:

$self->renderer->add_handler(json => sub {
my ($self, $c, $output, $data) = (@_);
$$output = JSON::XS->new->encode($data->{json});
});

At least, if I understood the renderer guts correctly...

[sri]

$self->renderer->add_handler(json => sub {
   my ($self, $c, $output, $data) = (@_);
   $$output = JSON::XS->new->encode($data->{json});
});

Can be done, but doesn't work for all the other aspects of the framework where Mojo::JSON is also used. (WebSockets for example)

Btw. Might be worth using Cpanel::JSON::XS to avoid problems with the author of JSON::XS. https://metacpan.org/pod/Cpanel::JSON::XS

--

sebastian

[Ben van Staveren]

On 01/16/2014 09:33 AM, sri wrote:
>> $self->renderer->add_handler(json => sub {
>> my ($self, $c, $output, $data) = (@_);
>> $$output = JSON::XS->new->encode($data->{json});
>> });
>>
> Can be done, but doesn't work for all the other aspects of the framework
> where Mojo::JSON is also used. (WebSockets for example)

Ah, okay didn't know that... what's your feeling on having an attribute
exposed in Mojolicious.pm that sets the JSON encoder/decoder class? Be a
bit of work to get that change worked through everywhere but feels a bit
cleaner to me, and turns it into a very explicit opt-in. Then again not
like I have time to code but...

[sri]

Ah, okay didn't know that... what's your feeling on having an attribute
exposed in Mojolicious.pm that sets the JSON encoder/decoder class?

Strong -1 vote from me... we've tried that before and it was terrible.

The Mojo::Base::XS approach just works, has no overhead for anyone who doesn't need it and requires no changes in core at all.

--

sebastian

[Ben van Staveren]

Point, but it'd still require playing shenanigans with Mojo::JSON, IIRC
people here weren't big fans of monkeypatching either but it it seems to
be what Base::XS does (and does in a sane fashion, IMO) so was just
trying to get a feel for what'd be considered "better" :D