Flame has asked for the wisdom of the Perl Monks concerning the following question:

Ok... I'll try to explain this as simply as possible.

I have a module I'm developing called GMS. It has a sub-module used in a tie command called GMS::MemberFile

Well the thing is... most of the people using GMS::MemberFile will already have GMS objects declared... however there is another GMS object held within GMS::MemberFile. Unfortunately, due to the purpose of the GMS module... it's object tends to be rather big, so I'm hopeing there is a practical means of having the main program and GMS::MemberFile share the same object with minimal programmer-side intervention. (Not me, but the person using the module)

I'm afraid I'm half asleep at the moment, so that may not have been very clear. If you want me to clarify something please ask.

Thanks to anyone that can help me.


"Wierd things happen, get used to it"

Flame ~ Lead Programmer: GMS
http://gms.uoe.org

Replies are listed 'Best First'.
Re: Same object, different packages
by dws (Chancellor) on Sep 19, 2001 at 08:13 UTC
    I'm hopeing there is a practical means of having the main program and GMS::MemberFile share the same object with minimal programmer-side intervention.

    This is possible.

    Nothing prevents you from either passing some instance $x of class X as an argument when tying a scalar to class Y, or tying a hash that contains a reference to $x. You can still hold on to $x, as can the tied scalar. It's up to you, though to ensure that $x's state remains valid if it is access both directly and through the tie API, and are side-effecting $x through both.

    It doesn't matter at all whether Y is a submodule of X.

[reply]
[d/l]
      To be more specific - there is no such thing as a sub-module, save in convention. Modules ABC and ABC::DEF have no relationship other than the following:
      1. The files live in relatively similiar directory structures.
      2. The programmer has a mental picture that they're related
      Perl doesn't make any package relationships for you.

      ------
      We are the carpenters and bricklayers of the Information Age.

      Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

[reply]
Re: Same object, different packages
by Sifmole (Chaplain) on Sep 19, 2001 at 16:43 UTC
    Since you used the word objects, I am going to operate as if your modules are classes.

    You could set up the new() method of the GMS class such that it returns a reference to a pooled (pool of one in this case perhaps) instance of the class. If no instance exists, then one is created and placed in the pool. Then later when the GMS::MemberFile is instantiated you can call the GMS->new() and get a reference back. Doing this will allow you to use one instance in a couple of different places.

    Another thing you might want to consider is whether your class design would be better off using inheritance. Without actual code I don't know whether this is the situation or not, but it might be worth entertaining.

[reply]
    Pool?
    by Flame (Deacon) on Sep 19, 2001 at 20:46 UTC
      Sorry, new term to me... what do you mean by 'pool'?


      "Wierd things happen, get used to it"

      Flame ~ Lead Programmer: GMS
      http://gms.uoe.org
[reply]
        Sorry. By "pool" I mean a collection of something -- in this a collection of existing instances.
[reply]

Back to Seekers of Perl Wisdom