in reply to How can I find the calling object?

I'm a little curious about your constraints...

  1. The result must be a reference to the object which called the sub.
  2. The reference to the calling object must be obtained on the fly (no saving it anyplace first to be retrieved later).
  3. No changes may be made to the calling object (say, to have it pass $self to the receiving object).

While they have provided some interesting (if somewhat baroque :-) solutions, I'd love to know what causes them in your particular instance?

For example, why can't you use Hook::LexWrap to temporarily override the method in question to stash the object somewhere for your later use (which would violate constraint (2) and (3)?

Just curious :-)

Replies are listed 'Best First'.
Re^2: How can I find the calling object?
by strider corinth (Friar) on Nov 19, 2002 at 14:46 UTC
    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.
[reply]
[d/l]
      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]
        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]

In Section Seekers of Perl Wisdom