Object oriented gui with Perl/Tk ... how can I make this work?

[Nataku]

Got a question for all you fellow Perl programmers out there.
Sometime recently I really got into Java because of an OOP class I was
taking at the university, and I have been attempting to apply what I
have learned to a Perl project I have been working on.

Everything seems to go pretty smoothly, and perl takes relatively well
to most OO stuff - but when I get to the GUI part of the program I hit
a rather annoying roadblock that I can't really seem to find a good
solution to. Basically I am attempting to create a class that will
contain a BrowseEntry widget along with a Listbox. When the user
selects a kind of category from the BrowseEntry, the Listbox should
update with all the entries from that particular category.

My problem arises when I get to assigning the command to the
BrowseEntry widget using the browsecmd hashkey/variable. I can only
assign a package function call to it, and as such - it kind of defeats
the whole OO aspect of it, since I cant keep multiple instances of it
around. The piece of code that follows should help to illustrate my
plight.

***************

sub Populate {
my ($self, $args) = @_;
$self->SUPER:opulate($args);

my $browseEntry = $cardLabFrame->BrowseEntry( -variable =>
\$currentSet,
-browsecmd =>
\&refreshList )->pack( -side => 'top' );
}

sub refreshList{
my $self = shift;

#This doesnt work because the $self that gets shifted in here
# is actually the browseEntry widget, and I have no way that
# I know of to reliably get back to my parent object since
# there is no THIS operator in perl.
}

****************

So hopefully with this visual aid you can see my quandry. Never mind
the fact that I havent actually added the Listbox yet ... I havent
gotten that far because of this issue I stumbled upon. I did think of
a hack to get back to the parent object, by storing a reference to the
actual $self I want within an unused hashkey inside of the BrowseEntry
widget, but that seems way to hacky for me.

So I appeal to the community at large. Can any of you think of a way
out of this without hacking the language?

Ben

 

[Uri Guttman]

N> Sometime recently I really got into Java because of an OOP class I
N> was taking at the university, and I have been attempting to apply
N> what I have learned to a Perl project I have been working on.

glad you realize that perl has better OO than java!

N> My problem arises when I get to assigning the command to the
N> BrowseEntry widget using the browsecmd hashkey/variable. I can only
N> assign a package function call to it, and as such - it kind of defeats
N> the whole OO aspect of it, since I cant keep multiple instances of it
N> around. The piece of code that follows should help to illustrate my
N> plight.

N> ***************

N> sub Populate {
N> my ($self, $args) = @_;
N> $self->SUPER:opulate($args);

N> my $browseEntry = $cardLabFrame->BrowseEntry( -variable =>
N> \$currentSet,
N> -browsecmd =>
N> \&refreshList )->pack( -side => 'top' );
N> }

use a closure for the callback and close on $self.

<untested>

my $callback = sub { my $widget = shift ;
$self->whatever(
$widget ) } ;

do that inside Populate and use it for the -browsecmd value. then call
whatever method you want in the same class as Populate. it has both the
widget passed in @_ and the Populate object closed on $self.

note: this could creates a data loop (the closure has $self which could
have $browseEntry which has $self!). so you need to be careful or you
may leak memory. you have explicitly break that loop to properly garbage
collect it. you can do that by clearing the values in $browseEntry
(maybe some tk destroy method?) and then deleting $browseEntry.

N> So I appeal to the community at large. Can any of you think of a way
N> out of this without hacking the language?

get the book object oriented perl which covers using closures with
objects for callbacks.

uri

 

[Nataku]

Interesting ... now why didnt I think of that?

Thanks for the suggestion - Ill go try that out tonight and see what
kind of success I have.

I wouldn't say perl has better OO than Java, I just enjoy writing Perl
code much more than Java. Java's strictness does allow for some
pretty nice development tools, but Perl is just so much more fun to
write.

 

[Uri Guttman]

<don't top post. read the group guidelines which are posted regularly>

N> Interesting ... now why didnt I think of that?

because java doesn't have closures and perl does?

N> I wouldn't say perl has better OO than Java, I just enjoy writing
N> Perl code much more than Java. Java's strictness does allow for
N> some pretty nice development tools, but Perl is just so much more
N> fun to write.

read the book object oriented perl and then try to tell me that
again. perl can run circles around java's OO. perl OO can be stricter or
looser, have many ways to create objects and call methods on them, do
late binding, multimethods and more. java is very narrow in focus and
has little OO flexibility.

uri

 

[Nataku]

Good news - it works, and I havent been able to detect any memory
leaks as of yet.

True, Java does not have them ... but im not a Java developer, I do
Perl for my living. I just did Java for classes, Perl is my passion -
and what work pays me for, at least currently. If need be I can learn
a different language, but I would rather not don a different guru hat.

 

[Ala Qumsieh]

sub Populate {
my ($self, $args) = @_;
$self->SUPER:opulate($args);

my $browseEntry = $cardLabFrame->BrowseEntry( -variable =>
\$currentSet,
-browsecmd =>
\&refreshList )->pack( -side => 'top' );

In the spirit of TMTOWTDI, Perl/Tk allows different ways to defined
callbacks, all explained well in the Tk::callbacks pods.

-browsecmd => [\&refreshList, $self],

Btw, there is a newsgroup that deals with Perl/Tk, comp.lang.perl.tk. Please
post pTk related questions over there.

--Ala