Re^2: How can I find the calling object?

Hehe. Ok. Quite a few people appear to be interested. Here goes:

I'm writing an LDAP browser using Tk. My goal is to use ONLY the standard Tk:: modules and Net::LDAP, for reasons relating to the architectures I'm designing it for. Halfway through production, though, I designed a really cool (I think) new interface for it, which requires widgets totally unavailable in the standard Tk module set. I needed to make them myself.

During one attempt to create such a derivative widget, I needed to teach a widget that doesn't properly support scrolling to update the scrollbar I had attached to it when it received the yview() call. But since I was doing the binding myself (and hadn't yet discovered the ConfigSpecs command) the only way to tell the widget where the scrollbar was was to set $widget->{ scrollbar } to a reference to the scrollbar widget, and use that to address it. That method was messy, and just the Wrong Way To Do It, in my mind. Since I was using the standard Tk modules, and only happened to be doing a minor adjustment to one widget, I didn't want to modify it extensively enough to use LexWrap or anything else (not that I knew about LexWrap at the time =).

That was what got me thinking about finding the calling object. It's the sort of thing which would've been useful to me in some other places, and I figured there must be a way. Turns out there are at least three.

I'm very new at making derivative Tk widgets. Awhile after I posted, I found out about ConfigSpecs. Being able to use that solved a lot of problems that finding the calling object would've created, so I ended up using it instead.

In the end, I wasn't looking for an answer to the problem I have just explained. I had already thought of ways to store and retrieve the object, and didn't want to be told that that's how I should do it. That's why I posted the question I did.
--
Love justice; desire mercy.

Comment on Re^2: How can I find the calling object? Download Code

Replies are listed 'Best First'.
Re: Re^2: How can I find the calling object? by demerphq (Chancellor) on Nov 20, 2002 at 14:06 UTC
Turns out there are at least three. Er, i would say the three you mentioned are the same, with subtle differences, but essentially the same. BTW, my personal feeling is that avoiding having to do this is the best way to proceed, but i understand your constraints. Yves --- demerphq my friends call me, usually because I'm late....	[reply]
Re^4: How can I find the calling object? by strider corinth (Friar) on Nov 20, 2002 at 14:36 UTC
Well, the two DB related answers are close, but one constrains me to name my object (or an intermediate object) DB, and the other doesn't. That makes them very different for my use. As for PadWalker, I don't think it uses caller() or DB at all. Most of its work is done in XS, if I recall. -- Love justice; desire mercy.	[reply]
Re: Re^4: How can I find the calling object? by demerphq (Chancellor) on Nov 20, 2002 at 16:31 UTC
Oh. Maybe im confused here. I thought that PadWalker wasn't suitable since @_ isnt a lexical. Maybe i havent read this thread closely enough (probably). And since I assumed that the PadWalker bit wasnt suitable it seemed likely you mean the caller() solution. As for the differences between the caller() implementation they are basically trivial. They all use the idea of using caller inside of the package DB. I lexically scope that package declaration, the other idea adds a subroutine to the DB namespace to make it "easier". Personally I like mine more... But im clearly biased. :-) BTW if you want a good snippet for seeing how to use caller like this (the one i learned all this from) have a look in Carp::Heavy Good luck. --- demerphq my friends call me, usually because I'm late....	[reply]