«

Hi,
My title is probably not clear, here it goes:

I have package A and I have created an object from that package in my
main prog.
This object has properties, and one of them is a new object from
package B.
Afaik, this is the HAS-A relationship.

Now my issue is to call a method from package A from within a method in
package B...
I could give the object (created off package A) as an argument, but I
guess there might be a nicer way to achieve that ? or my design is
crappy ??

Ex:

in main prog:
--------------
$obj = Server->new();
$obj->createSession();
$obj->doSomething();


in package Server:
-------------------
sub createSession {
my $self=shift;
$self->{session} = new Session();

}

sub doSomething {
my $self=shift;
$self->{session}->doTask();
}

sub returnServerDetails {
my $self = shift;
# here i return a property of the created object ($obj)
return $self->{one_property};
}


in package B:
--------------
sub doTask {
my $self =shift;
# here i want to call server::returnServerDetails, but i want it
to be
# aware that i'm talking about the object that created me ($obj)
# because i need some properties about the Server that
# created me... and I need to call several methods from package
Server
# which will return info about it.
}



Thanks for your help !
regards,
why-em-jay

why-em-jay wrote:
> Hi,
> My title is probably not clear, here it goes:
>
> I have package A and I have created an object from that package in my
> main prog.
> This object has properties, and one of them is a new object from
> package B.
> Afaik, this is the HAS-A relationship.
>
> Now my issue is to call a method from package A from within a method in
> package B...
> I could give the object (created off package A) as an argument, but I
> guess there might be a nicer way to achieve that ? or my design is
> crappy ??

I'm not sure I would call it "crappy", but your design does need some
rethinking.

The Session object has absolutely no idea that a reference to it is
stored inside a Server object. There's no way for it to have that
knowledge. Consider:
my $server = new Server;
my $server2 = new Server;
$server->createSession();
# $server->{session} is a Session object.
$server2->{session} = $server->{session}.

Now you've got a reference to a single Session object stored in two
different Server objects. Under your design, which Server would the
Session object's doTask method want to be working with?

The central issue here is that while there is a "has a" relationship
(as you called it) from the Server object to the Session object, there
is no corresponding backwards relationship from the Session to the
Server. No object of any kind has any intrinsic way of knowing where
every reference to it is stored.

The obvious way to get the results you're looking for is the method you
suggested:

$server->{session}->doTask($server);

Paul Lalli

"why-em-jay" <> wrote:

> Hi,
> My title is probably not clear, here it goes:
>
> I have package A and I have created an object from that package in my
> main prog.
> This object has properties, and one of them is a new object from
> package B.
> Afaik, this is the HAS-A relationship.

correct.

> Now my issue is to call a method from package A from within a method in
> package B...

The only clear way I can think of this is to have A register a call back
with B.

--
John Small Perl scripts: http://johnbokma.com/perl/
Perl programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html

Paul Lalli <> wrote in comp.lang.perl.misc:
> why-em-jay wrote:
> > Hi,
> > My title is probably not clear, here it goes:
> >
> > I have package A and I have created an object from that package in my
> > main prog.
> > This object has properties, and one of them is a new object from
> > package B.
> > Afaik, this is the HAS-A relationship.
> >
> > Now my issue is to call a method from package A from within a method in
> > package B...
> > I could give the object (created off package A) as an argument, but I
> > guess there might be a nicer way to achieve that ? or my design is
> > crappy ??
>
> I'm not sure I would call it "crappy", but your design does need some
> rethinking.
>
> The Session object has absolutely no idea that a reference to it is
> stored inside a Server object. There's no way for it to have that
> knowledge. Consider:
> my $server = new Server;
> my $server2 = new Server;
> $server->createSession();
> # $server->{session} is a Session object.
> $server2->{session} = $server->{session}.
>
> Now you've got a reference to a single Session object stored in two
> different Server objects. Under your design, which Server would the
> Session object's doTask method want to be working with?

Well, the intent seems to be that a session is handled by only one
server. Then the program logic would be so that the case you mention
doesn't happen.

> The central issue here is that while there is a "has a" relationship
> (as you called it) from the Server object to the Session object, there
> is no corresponding backwards relationship from the Session to the
> Server. No object of any kind has any intrinsic way of knowing where
> every reference to it is stored.

This, of course, is right, no matter what the program logic.

> The obvious way to get the results you're looking for is the method you
> suggested:
>
> $server->{session}->doTask($server);

One could give the Session object a field that points back to the "its"
server. Since Session->new is called from a Server method, that is
easily done:

sub createSession {
my $server = shift;
$server->{ session} = Session->new( $server);
# ...
$server;
}

Session->new simply stores the server away for later use in

$server->{ session}->doTask;

which now doesn't need the parameter.

The circular reference that is created may pose a problem. In a long-
running program that processes many servers and sessions, it may be
necessary to weaken one of the refs and have a DESTROY method in
Session and/or Server. That lessens the fun somewhat.

Anno
--
If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.