interest in converting LWP / Mech hierarchy to roles?

[Mark Stosberg]

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

[Ovid]

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/

________________________________
Sent: Wednesday, 27 February 2013, 17:04
Subject: interest in converting LWP / Mech hierarchy to roles?
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
    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;
    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
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]

Post by Mark Stosberg
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 => ***@petdance.com => www.petdance.com => AIM:petdance

[Mark Stosberg]

Post by Andy Lester

Post by Mark Stosberg
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]

Post by Mark Stosberg
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

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

[Mark Stosberg]

Post by Andy Lester

Post by Mark Stosberg
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]

Post by Mark Stosberg
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]

Post by Yanick Champoux

Post by Mark Stosberg
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]

Post by Mike Doherty

Post by Yanick Champoux

Post by Mark Stosberg
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 :)

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]

Post by Mark Stosberg
There's so many modules that extend LWP or Mechanize through
sub-classing, but can't easily be combined with getting into diamond
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