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. See also http://leonerds-code.blogspot.com/2011/05/wearing-two-hats.html TMTOWTDI, after all... -- Paul "LeoNerd" Evans leonerd@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/