The fact that callback interfaces are uncommon is not a factor in calling that of File::Find abysmal, in my opinion. I do think it's a very poor design, but for reasons other than that it's supposedly hard to understand. File::Find's approach to the problem domain is one of absolute minimalism, and it's hard to conceive an even more barren interface.
As a result I find that accomplishing nontrivial tasks using File::Find results in messy and hard to read code, no matter how hard I try to fix this. Concerns are hard to separate in any concise fashion. But File::Find is even worse than the previous implies because not only does it make hard things difficult, it also makes trivial things unnecessarily involved. Simply getting a list of files or directories requires too much setup, f.ex.
In short, there's never a situation where the interface is a natural fit. Parts of a program that deal with calling File::Find::find() always feel like a wart.
File::Find::Rule shows how things can be done better: an interface tailored to common tasks in the problem domain improves expressiveness and readability and makes it easier to separate concerns.
Makeshifts last the longest.
In reply to Re: File::Find considered hard?
by Aristotle
in thread File::Find considered hard?
by Jenda
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |