Re: Re: goto and AUTOLOADed methods

I agree, autoloaded accessor are probably a bad idea but that's not what I was doing. Did you read my comment on what I was actually doing with AUTOLOAD?

Another use I had was an object proxy. Basically you connect to an object server, get an ID from that server, it gets wrapped in an object on the client side which looks like

package ProxyObject;

sub AUTOLOAD
{
  my $self = shift;
  $method = $AUTOLOAD;
  $method =~ s/.*:://;

  return $self->{HomeServer}->call_method($method, $self->{ID}, \@_);
}
[download]

the HomeServer object sends the method, the id and the args back to another server which calls the method on the correct object, passing in the args and then passes the result back across the network.

In use it looked like


my $server = Server->connect(
  host => auth.domain.com
  user => $user,
  pass => $pass
);

my $root = $server->getRoot; # this is a proxied object
my $users = $root->getUsers; # another proxied object
my $fergal = $users->getUser("fergal");
$fergal->setPasswd("wibble");
$fergal->setShell("/bin/zoidberg");
$fergal->commit;
[download]

Your Perl code neither knows nor cares that some of the objects it's playing with doesn't actually exist on this machine.

Comment on Re: Re: goto and AUTOLOADed methods Select or Download Code

Replies are listed 'Best First'.
Re3: goto and AUTOLOADed methods by dragonchild (Archbishop) on Aug 01, 2003 at 17:21 UTC
Why wouldn't you use something like SOAP::Lite here? (Please note that I'm a SOAP novice, but it seems like it would do the trick here ...) ------ We are the carpenters and bricklayers of the Information Age. The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6 Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.	[reply]
Re: Re3: goto and AUTOLOADed methods by fergal (Chaplain) on Aug 04, 2003 at 11:10 UTC
I looked at SOAP, thinking it might solve all my problems but SOAP seemed to me at the time to be for 1 shot remote calls. You send some data, you get some data back. You don't get an object that you can then call methods on just like any other object that your program uses. The data that comes back is just hashes and arrays etc, no objects. Of course you could then wrap up the data that came back in an object and call methods on it, which is basically what I was doing except I wasn't using SOAP to transmit the arguments and results of the function calls. The other difference is that SOAP doesn't have persistent connections so the server keeps having to save and restore the object from a database every time you call a method on it. The system I wrote maintains 1 process for every connection to it. Not ideal in some situations but exactly what I needed for my situation. Possibly more like J2EE, but I coudn't be sure about that.	[reply]