On Sat, Dec 15, 2018 at 07:31:48PM +0100, Ingo Schwarze wrote: > That's typical for pkg_add(1). There are few programs in the tree - > even including unmaintained legacy stuff - where it is harder to > find anything. In pkg_add(1), code for each object is typically > scattered across many files, each file typically mixes code for > many different objects, the filenames almost never correspond to > the names of the objects they implement, and many functions are so > small that they do almost nothing, making call trees hard to unravel.
That's object-oriented code for you. Looks like you have some issues with that. One thing that makes things slightly harder is practicality. Contrary to compiled languages, the code for pkg_add does install directly. So I could have a lot of very small files, each implementing one single class. I'm pretty sure you would not like it. And I'm certain Theo would violently oppose such a move. As for small functions being all over the place, that's the Visitor pattern for you. In the case at hand, I don't think ProgressMeter is a hard name to guess. Being OO, there's a default stub class that kicks in when pkg tools are not run in a terminal. Along with a sizer helper class, used to know what % it's supposed to display (which is also stubbed out, since there's no need to compute much by default The default code that actually does things lives in ProgressMeter/Term.pm it does actually rely on other perl libraries (Term::Cap for the control sequences and Term::ReadKey for the terminal size...), so having it trigger by default is expensive...
