in reply to Missing base classes when called from Tk

I (sort of) wish I could help you with whatever OO incantations are missing or misfiring in your code, but I can't -- I hope some other monk can help with that. I just was curious about why you're doing this...

I had program working in non-object oriented mode and have been converting to object oriented

Um, if it wasn't broke, why are you "fixing" it?

(only 2.3x in size (751 lines ->1776 lines), so far; :-) ).

It must be my own naivete regarding OO concepts (which are admittedly somewhat foreign to me still), but I would have expected that a "proper" OO design would yield fewer lines of code than an old-fashioned procedural/structured design.

If you have a working non-OO version, and an equivalent OO version would entail writing 2 or 3 times more lines of code, what exactly is the benefit you derive from an OO solution, such that it would offset all the extra effort to create it (and presumably, with so many more lines of code, the extra maintenance load that it's likely to impose)?

  • Comment on Re: Missing base classes when called from Tk

Replies are listed 'Best First'.
Re^2: Missing base classes when called from Tk
by perl-diddler (Chaplain) on Sep 27, 2007 at 08:19 UTC
    Well, working is one thing, but it was getting a bit over-sized for its britches and it wasn't in a form I wanted to enhance it in. I expect the lines / functionality ratio will go down eventually. :-) It's also a learning/educational thing.

    Like somehow I don't quite yet see how OO is supported in perl. Is the machinery to trace my back my ancestor namespaces in the perl binary or some perl code? Shouldn't it just look in the "handler (key or timer handler) routine's namespace for an @ISA? Then "it" (whatever it is), follows the package list depth-first, left-to-right? Yes? (or no...) But that sequencing doesn't seem to explain why it's not "properly" searching parent class (package) for matches after the current package when called from Tk in a callback function.

    l