interest in converting LWP / Mech hierarchy to roles?

Mark Stosberg

unread,

Feb 27, 2013, 11:04:05 AM2/27/13

to perl-qa

There's perhaps no better illustration of the values of roles vs
inheritance in CPAN modules than the mess than that the LWP inheritance
tree.

There's so many modules that extend LWP or Mechanize through
sub-classing, but can't easily be combined with getting into diamond
inheritance:

Here's a sampling of LWP subclasses:

WWW::Mechanize
LWP::UserAgent::POE
Test::LWP::UserAgent
LWP::UserAgent::Cached
LWP::UserAgent::ProxyAny;
LWP::UserAgent::Snapshot;
LWP::UserAgent::Keychain;
LWP::Parallel::UserAgent;
LWP::UserAgent::Determined;

Then you have the WWW::Mechanize sub-classes. Here's a sampling:

Test::WWW::Mechanize
WWW::Mechanize::Query
WWW::Mechanize::Cached
WWW::Scripter

Now, if you'd like to combine one of these of the features extensions
from any these, good luck! Trial-and-error, and possible @ISA-hacking
lie ahead of you. Maybe you'll find a valid combination. Maybe not.

Now, if the extensions were written as roles, combining the extensions
would be. There could still be conflicts and incompatibilities, but I
think things would be far more likely to present themselves up front.

Perhaps if some of these get converted to extend-by-roles instead of
extend-by-inheritance, some others will follow along, and we'll end up
with a more useful of collection of Perl-based browser extensions.

Mark

Andy Lester

unread,

Feb 28, 2013, 10:45:47 AM2/28/13

to Mark Stosberg, perl-qa

On Feb 27, 2013, at 10:04 AM, Mark Stosberg <ma...@summersault.com> wrote:

> Then you have the WWW::Mechanize sub-classes. Here's a sampling:
>
> Test::WWW::Mechanize

As far as Test::WWW::Mechanize goes, I don't see that the testingness is really a role. It's really mostly a bunch of wrappers and some convenience functions.

--
Andy Lester => an...@petdance.com => www.petdance.com => AIM:petdance

Ovid

unread,

Feb 28, 2013, 10:42:08 AM2/28/13

to Mark Stosberg, perl-qa

Hi Mark,

I think this is a fantastic idea! I actually think that much of this could be done very easily via a "has-a" relationship and delegation in the role. Thus, the roles themselves can be put together very quickly. The downside is maintaining them in case the modules they depend on change.

Cheers,
Ovid
--
Twitter - http://twitter.com/OvidPerl/
Buy my book - http://bit.ly/beginning_perl
Buy my other book - http://www.oreilly.com/catalog/perlhks/
Live and work overseas - http://www.overseas-exile.com/

>________________________________
> From: Mark Stosberg <ma...@summersault.com>
>To: perl-qa <per...@perl.org>
>Sent: Wednesday, 27 February 2013, 17:04
>Subject: interest in converting LWP / Mech hierarchy to roles?

Mark Stosberg

unread,

Feb 28, 2013, 11:26:07 AM2/28/13

to perl-qa

On 02/28/2013 10:45 AM, Andy Lester wrote:
>
> On Feb 27, 2013, at 10:04 AM, Mark Stosberg <ma...@summersault.com

> <mailto:ma...@summersault.com>> wrote:
>
>> Then you have the WWW::Mechanize sub-classes. Here's a sampling:
>>
>> Test::WWW::Mechanize
>
> As far as Test::WWW::Mechanize goes, I don't see that the testingness is
> really a role. It's really mostly a bunch of wrappers and some
> convenience functions.

Thanks for the feedback, Andy.

I'd like to have a Mechanize that has both the testing functions, and
also JavaScript support, which the WWW::Scripter sub-class has.

I haven't looked closely into it, but the surface it seems like I should
be to combine a "does testing" role with a "does javascript" role to
achieve this result.

Mark

Andy Lester

unread,

Feb 28, 2013, 11:29:21 AM2/28/13

to Mark Stosberg, perl-qa

On Feb 28, 2013, at 10:26 AM, Mark Stosberg <ma...@summersault.com> wrote:

> I'd like to have a Mechanize that has both the testing functions, and
> also JavaScript support, which the WWW::Scripter sub-class has.

Seems to me even better would be to fold WWW::Scripter's JS support into Mech itself.

xoa

Mark Stosberg

unread,

Feb 28, 2013, 11:30:06 AM2/28/13

to perl-qa

On 02/28/2013 11:29 AM, Andy Lester wrote:
>
> On Feb 28, 2013, at 10:26 AM, Mark Stosberg <ma...@summersault.com

> <mailto:ma...@summersault.com>> wrote:
>
>> I'd like to have a Mechanize that has both the testing functions, and
>> also JavaScript support, which the WWW::Scripter sub-class has.
>
> Seems to me even better would be to fold WWW::Scripter's JS support into
> Mech itself.

Good to hear! I've shared this comment with the WWW::Scripter maintainer.

Mark

Yanick Champoux

unread,

Feb 28, 2013, 12:07:31 PM2/28/13

to Mark Stosberg, perl-qa

On 13-02-27 11:04 AM, Mark Stosberg wrote:
> Perhaps if some of these get converted to extend-by-roles instead of
> extend-by-inheritance, some others will follow along, and we'll end up
> with a more useful of collection of Perl-based browser extensions.

I don't have a lot to add to the conversation at the moment, but I just
wanted to '++' the idea, a I think it's a very, very good one. To be
able to effortlessly combine any number of the Mech-based modules
together would be awesome. Voltron-level awesome. :-)

Joy,
`/anick

Mike Doherty

unread,

Feb 28, 2013, 3:26:40 PM2/28/13

to per...@perl.org

On 13-02-28 09:07 AM, Yanick Champoux wrote:
> On 13-02-27 11:04 AM, Mark Stosberg wrote:
>> Perhaps if some of these get converted to extend-by-roles instead of
>> extend-by-inheritance, some others will follow along, and we'll end up
>> with a more useful of collection of Perl-based browser extensions.
>
> I don't have a lot to add to the conversation at the moment, but I
> just wanted to '++' the idea

Same here. I've had two separate projects at university that both would
have been easier had the LWP stuff been done as roles. As it seems
everyone thinks this is probably a good idea, the real question becomes
"Who is going to do the work?" -- as usual :)

-Mike

Mark Stosberg

unread,

Feb 28, 2013, 5:07:09 PM2/28/13

to per...@perl.org

One of the nice parts about this, is that it can be backwards
compatible. For example, if we wanted to make this change in
WWW::Mechanize, we could make WWW::Mechanize::Role, and move (hopefully)
all the functionality in there, and then WWW::Mechanize would like this:

package WWW::Mechanize;
use Moo;
extends 'LWP::UserAgent';
with 'WWW::Mechanize::Role';
1;

I mocked this up with Moo, as it's both Moose-compatible, and a lighter
dependency. Any other Moose-compatibile role option seems like it would
be a fine choice.

People could go on using WWW::Mechanize as they have been, but now
there's a new option to use it a role in a complex user agent if desired.

Mark

Eric Wilhelm

unread,

Mar 8, 2013, 1:10:08 AM3/8/13

to per...@perl.org

# from Mark Stosberg on Wednesday 27 February 2013:

>There's so many modules that extend LWP or Mechanize through
>sub-classing, but can't easily be combined with getting into diamond
>inheritance:
>
>Here's a sampling of LWP subclasses:

> LWP::UserAgent::POE
>...
> LWP::Parallel::UserAgent;

And you forgot LWP::Iterator::UserAgent, HTTP::Async,
AnyEvent::HTTP::LWP::UserAgent, LWP::Protocol::Coro::http, and
Net::Async::HTTP.

Not all of these are subclasses or extensions, some are probably re-
implementations due to the difficulty of bolting a non-blocking workflow
onto a blocking object. Given some finer-grained composition, maybe
various add-on features could be easily used from any of these various
engines / event loops.

--Eric
--
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------