in reply to Object passing within a package

This situation looks a bit odd. Why are you creating another object inside a method call and using that as an argument to another method?

You don't need to create a reference to your $FooObj reference, so you can lose the backslash in front of it when you call barsub. If you are seeing odd behaviour, ensure $FooObj is actually an object.

package Foo::Bar; use base 'Foo'; sub foosub { my $self = shift; my $FooObj = Some::Module->new; die "Not an object!" unless ref $FooObj eq 'Some::Module'; $self->barsub( $FooObj ); } sub barsub { my $self = shift; my $FooObj = shift; ... }
--
brian d foy <bdfoy@cpan.org>

Replies are listed 'Best First'.
Re^2: Object passing within a package
by naChoZ (Curate) on Jan 17, 2005 at 18:20 UTC

    Yes, your code is pretty much identical to what I ended up using to get past that particular problem.

    Specifically, what I'm trying to write is a Curses::UI interface to a sort of psuedo-autodiscovery script. I was attempting to figure out how to pass the Curses::UI objects around without declaring full-blown globals. I'm also trying to write it in such a way that it could potentially interface with a different autodiscover script.

    So essentially I have MyModule, MyModule::Interface::CLI, and MyModule::Autodiscover. I wanted to contain all the C::UI stuff in M::I::CLI, which is why I was trying to pass those C::UI objects to different subs within the M::I::CLI package. If I'm poorly reinventing a wheel, I certainly welcome input.

    And yes, I do spend too much time monkeying with RT.

    --
    "This alcoholism thing, I think it's just clever propaganda produced by people who want you to buy more bottled water." -- pedestrianwolf

      Hmmm... if all things need to access the Curses::UI object, you might consider creating giving each of their objects a reference to the Curses::UI object. It should be the same object (so you don't have multiple ones), but then every time you call a method, you already have it in the object data. In that case you don't need to pass it around.

      Sometimes the Singleton design pattern can solve this little sanfu, too. There is a Perl Singletons on Perl Monks, or my article about Singletons in The Perl Review, Issue 0.1

      --
      brian d foy <bdfoy@cpan.org>

        That's great. At the time I didn't know what it was called at the time, but Kanji showed me a singleton construct one time. I just couldn't quite figure out how to apply it to what I was doing here. This was very helpful. Thanx!

        --
        "This alcoholism thing, I think it's just clever propaganda produced by people who want you to buy more bottled water." -- pedestrianwolf

Re^2: Object passing within a package
by dragonchild (Archbishop) on Jan 17, 2005 at 16:53 UTC
    This situation looks a bit odd. Why are you creating another object inside a method call and using that as an argument to another method?

    First, why must barsub() be a method? Why isn't it a function?

    I can think of at least two reasons to do this:

    1. barsub() is a utility function defined to do something useful. barsub() may actually be _barsub().
    2. barsub() is a utility function that comes from some other library of functions.

    As for why foosub() instantiates the Some::Module object then passes it to barsub(), you could have foosub2() that instantiates an object from Other::Module and passes it to barsub().

    You just never know.

    Being right, does not endow the right to be rude; politeness costs nothing.
    Being unknowing, is not the same as being stupid.
    Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
    Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

      In the example, it looks like barsub() in that same package as foosub(), which is a method. If barsub() has nothing to do with that same package or object, it's in the wrong place. If the situation is different, then the example code has way too much detail, and we don't need to know anything about anything else than barsub().

      I don't know what the original poster is doing, but it looks like an odd design. That's why I asked. I'm not trying to guess what the he is actually doing. I'm just asking why he's doing it that way, and I'll wait to see what he says, and then I'll know (which is sooner than never ;).

      --
      brian d foy <bdfoy@cpan.org>