> So the error is actually just that: an error indicating that the module > will not work, because AnyEvent is NOT an event library and lacks the > functionality (which was present in earlier versions). If I delete the die, my code continues to run fine. A loud warning indicating that you think the module is a bad idea and refuse to even speak to me if it breaks I wouldn't object to. > Ah, but it's buggy and causes mysterious failures that are hard to > diagnose for users after the required functionality had been removed. This > has been reported, and the author of IO::Async::Loop::AnyEvent has had > ample time to fix it. "mysterious failures that are hard to diagnose" in AnyEvent::Impl::IOAsync was my reason for doing this in the first place. I had time scheduled by the client to find the bug and try and contribute a patch up until the die() hit CPAN; that evaporated with their decision to switch away. > I am not the author of IO::Async::Loop::AnyEvent, and am not responsible > for it when it breaks. Making me responsible is highly disingenious. I'm not. I'm making you responsible for issuing an unstoppable die() just because it's loaded. At no stage have I argued that what I was doing was the best possible idea, merely the expedient one to allow me to get software providing business value into production in the timescale required by the customer. Telling the user that the gun is pointed at their foot and disclaiming all responsiblity I don't mind in the slightest, but if I have a good reason to do so then there should still be a way for me to say "I know, damn it, let me do it anyway". If I didn't want that, I already know where @other_langs live. -- Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue http://shadowcat.co.uk/blog/matt-s-trout/ http://twitter.com/shadowcat_mst/ Email me now on mst (at) shadowcat.co.uk and let's chat about how our Catalyst commercial support, training and consultancy packages could help your team.Thread Previous | Thread Next