File::Finder one-upped File::Find quite nicely.
His replacements have usually been good. I tend to look at hold his modules, Damian's, Simon Cozens', and Brian Ingerson's a little higher in regard ... but only because respect is earned. They write things that do good work for me.
Note: I'm not Merlyn.
| [reply] |
I think you mean File::Finder vs File::Find::Rule. And in fact, that's true. I looked at the prior art in File::Find::Rule, even the implementation, and decided I could do better. And I both acknowledge that in the docs (about FFR), I also embrace the existing FFR plugins with my own "ffr" method in File::Finder.
But everyone seems uppity that I'm trying to do the same thing with CGI::Application. No, please, no. I looked at everything out there for what I needed for my client. Nothing worked. I didn't set out to define a "better CGI::Application". I set out to define a generic MVC metacontroller that would easily subclass to be the controllers I needed for a few of my clients. Nobody has done that. CGI::Application isn't it, nor does it pretend to be it.
So, please stop comparing this to CGI::Application, any more than you'd compare Template Toolkit to Embperl. They're not the same class of framework. They have different goals.
| [reply] |
I still don't understand why File::Finder is better than File::Find::Rule. I haven't looked into the internals, but the FFer API feels much clunkier than FFR's. I've given the module the benefit of the doubt repeatedly, but it just feels like a step back from FFR.
How exactly did you intend for FFer to be better than FFR?
Makeshifts last the longest.
| [reply] |
