???
Can you explain how you arrived at such a nonsensical conclusion?
I've tried splitting a project early on into modules,
it was a constant bother trying to find where a routine was -- in this window or that window -- is a window with that file even open? 'edit' -- oops -- file is being doubly diddled -- half the time on my other machine ---- so it's not listed with the same group as the other files... but those are minor oopses..
The time wasted finding functions that need to be updated or interfaces that need to be updated/changed over multiple files because they are just being fleshed out and not really really to be split -- or really weren't designed to exist independently, but were, because perl can't easily have multiple classes in 1 file (as is demonstrated in the **beginner** books on perl OOP (Intermediate Perl).).
The introduction to classes by the experts doesn't demonstrate using "use" to use other Class objects. It shows them all in one file. That's the starting point that almost nothing follows afterwards.
Yet that's the first book (or it's predecessor by a different title), on perl classes and packages that someone would be likely to read. Yet nothing in perl works that way.
You don't see a problem with that?
Why doesn't anyone program the way Schwartz & bdfoy, and t.phoenix demonstrated? Do Schartz and bdFoy know nothing about perl.
Why would the perl community support a perl that burns anyone who programs they way Schwartz and bdFoy taught? That's not to say they use that paradigm for everything, but for
Dog says bark, and Cow says moo, separating things into 5 separate files would turn off anyone.
|