I would tend to wish, vainly, that authors would put good faith efforts into doing things that were generally useful and that don't have mysterious failuremodes, that work equally well on multiple platforms (or at least with that intention), that don't fail just because my other perl code didn't look enough like what the author expected. Its a wish. A vain wish. I know. It is unhelpful to have you point out that it is nothing more than a wish and I also wish you hadn't done that. Actually, I think its more than a wish but a bit of a community expectation that authors should at least try for that. I expect that one way of reaching those goals is to avoid such obviously perilous and known impossible jobs. Impossible in the general sense anyway, I'm quite sure that the author's code works more often than it doesn't mostly because I have faith that the author put at least a little bit of effort into it.
People who don't even try to make reasonable stuff for CPAN ought to have something anatomically improbable done to them. I wish them ill and hope their efforts fail everywhere they go.
The only non-parse related method I know to rewrite perl code is to treat perl like lisp and rewrite it at the optree level. At least then there are no ambiguities about how something is parsed - its all been handled by the perl parser. But then, perl is an exceptionally ugly lisp when viewed from that direction.
In reply to Re^5: When is it better to NOT release a new module?
by diotalevi
in thread When is it better to NOT release a new module?
by snowhare
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |