develooper Front page | perl.perl5.porters | Postings from January 2012

Re: [perl #108470] Term::ReadLine should use AE instead of Tk forevent looping

Thread Previous | Thread Next
From:
demerphq
Date:
January 19, 2012 08:57
Subject:
Re: [perl #108470] Term::ReadLine should use AE instead of Tk forevent looping
Message ID:
CANgJU+WZhAA8u3+a31cxdxFZ_wWikoAY1xjm7+7PK--ejtfYZQ@mail.gmail.com
On 19 January 2012 17:42, Paul LeoNerd Evans <leonerd@leonerd.org.uk> wrote:
> On Thu, Jan 19, 2012 at 01:01:39PM +0100, demerphq wrote:
>> > Interoperability requires cooperation from the author, and he's been known to break it for modules he doesn't like.  Ask Paul Evans and/or Matt Trout about this:
>> >
>> > https://metacpan.org/source/MLEHMANN/AnyEvent-6.13/lib/AnyEvent.pm#L1396
>> >
>>
>> Wow.
>>
>> IMO the author of IO::Async::Loop::AnyEvent should just redefine
>> AnyEvent::detect() to bypass this monstrosity.
>>
>> But if they do are we going to see an arms race over what modules you
>> allowed to use with other modules?!
>
> I'm not going to get into a silly childish arms-race over this issue.
>
> MLEHMANN is upset because I found a way to layer IO::Async atop AnyEvent
> instead of vice versa, but doing so required a small peek inside the
> internals to obtain one feature the AE API doesn't provide (namely, a
> "run this piece of code after the next event timeslice"). Were that
> added, there could be no possible objection to
> IO::Async::Loop::AnyEvent, as it becomes simply another AE-API using
> module.
>
> He choses not to do that, thus forcing me to peek inside, and so he gets
> upset.
>
>> I consider the piece of code you pointed out to most unperlish, and an
>> affront to the community and the spirit of CPAN.
>
> Which again is why I'm not going to get into an arms race as it will
> only end badly.
>
>> IMO AnyEvent should be removed from CPAN until this code is removed,
>> it seems inappropriate for CPAN to host code that forbids you from
>> using something else on CPAN.
>
> That seems a -little- OTT as a response, surely? Perhaps a far better
> solution would simply be to bring this change to more people's
> attention, and point out that other alternatives exist (namely
> IO::Async, POE and Reflex come to mind); and that people should be free
> to decide which one(s) they want to use.

Yeah, its probably OTT as a response. And I am glad you aren't going
to start an arms race over it.

I guess I shouldn't let it bother me, but it just seems wrong to do
something like that: the antithesis of the intent of CPAN and sharing.
"You can only use my module if you obey my rules" does not seem to be
the right attitude for something on CPAN.

I actually checked to see if Larry Wall had said anything relevant
about stuff like this and I found two quotes I think fit:

from perlstyle:        ·   Be nice.
from Larry Wall*: Perl doesn't have an infatuation with enforced
privacy. It would prefer that you stayed out of its living room
because you weren't invited, not because it has a shotgun

Seems to me that the code we are discussing violates both.

cheers,
yves



* http://www.goodreads.com/quotes/show/81807




-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About