I've somehow broken Perl's OO mechanism.
When calling through a blessed reference, it is not finding
(nor, apparently, searching) methods in "Base" or ancestral
classes....
Not if this is "a" or "the" right forum or which would be better
if this isn't a right place.
I tried running it by perlmonks, but no luck in progressing
there. I'm using Tk on Win32(XP) cygwin. I seem to have
some odd interplay with "Tk" event handlers and
ancestor searching.
I have an Object Oriented hierarchy, with multiple packages in
one file. It's structured like using package names (from most Base
to most Derived) of "ONE", "TWO" "THREE", and "FOUR",
where each builds (has an @ISA relation) on the previous class.
I'm setting up two event - handlers, both were in package THREE
and was on my way to splitting the 2nd to class "FOUR" when
unexpected errors prompted me to temporarily disable the 2nd event
(timer) altogether. The first is an event handler for all
keys in TK (bound to a "main window").
The symptom I'm running into is that I setup the "key_handler"
in package THREE, pointing to a "keybd handler" (also in
THREE). According to the man page, the event (key)
handler in package "THREE" is called using the form:
"$main_window_blessed_reference -> Tk_Event_Handler ( \
<extra programmer specified arguments to be passed>)"
The handler is "bound" to the "main_win" in a package "THREE"
method. The package THREE method is passed $s ($self) in the
first param (as "normal"). It is the "one" handle that is
opened in "main" for the life of the program (i.e. most
derived class is a singleton).
When I bind the event handler, I ask for 3 parameters to be passed
to the handling function (in addition to the "main_win" handle it is
called through): the "singleton" handle and 2 key-id values:
sub __bind_events_to_main_win ($) {
my ($s,$main_win) = @_;
my $retval;
$retval = $main_win -> bind('<Any-KeyPress>' =>
[\&__handle_key, $s, Ev('A'), Ev('K')]);
}
The handler uses the stored "blessed singleton handle" in "$s" (self)
as the base for future object references. However, as soon
as a level "THREE" package tries to call a method in an ancestral
class, I get a Tk:Error message along the lines of
"THREE::<ancestral-method not found>" -- it doesn't seem to be
searching ancestral class TWO or ONE for "ancestral-method".
The pointer ($s) passed to "handler" is of the same "class" (ref)
as the level it was bound and called in (same levels). When I
call through the pointer (in the handler routine), I'd "expect"
perl would (1) see the Class of the reference I am calling
through, look in the symbol-table for that Class for "@ISA()"
and follow the chain back to find Base classes, but that's not
what it is doing. It seems to not look through any Base
classes.
Stack traceback in debugger shows my handler routine called
by a "Tk" "eval", don't know if that is related ('theoretically
shouldn't be)...
Another minor, but perhaps salient point, is that all the packages
are in one (1) file. The separation of routines into
different classes/packages is more for grouping & ordering
the objects/levels conceptually than it is to split it into
several files (which would be a detraction, actually).
It might be that I'm simply confused about what I am doing and
shouldn't expect Base classes to be called through a blessed
reference, except the debugger (perl -d script.pl) is as confused
as I am.
I use the 'm' command in debug and on the blessed reference
I am calling through. The debugger prints out all the
methods for the current class (THREE) and then lists
available methods in classes(packages) TWO and then ONE.
It seems that the debugger thinks I am calling through a
class pointer with two ancestral classes -- but if I try to
single step or continue, it goes off to Tk::Error with the Warning
"THREE:<ancestral class in ONE or TWO not found>" at
<breakpoint I just continued from> instead of passing control
to the package ONE or package TWO method.
As if to "accentuate" the breakdown of perl's OO method, if I
want to call a method in an ancestral class, I can provide
the same named method (in THREE) and chain the call with SUPER.
But this is [obviously], a *hack* for debug/testing purposes.
How can a call through a blessed reference "NOT" look through
Base classes?
Am sorta stuck at this point, -- if I have to manually add
"proxy" routines in "THREE" to call the parental methods, that
really defeats the purpose of going "OO", no? It appears
perl's OO mechanism isn't working as expected. Why doesn't it
auto search the Base classes at exec time when it *does* show
the methods (in the Base classes TWO and ONE) in debug?
Anyone have any ideas why this might be happening? (known bug in
Tk, or OO, or whatever....?)
Tnx,
Linda
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Perl-Win32-GUI-Users mailing list
Perl-Win32-GUI-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
http://perl-win32-gui.sourceforge.net/
