Re: A caller() by any other name

[xdg]

It's a little hard to know what you mean, but if you want Object A to call a method on Object B and have B know that A was the object that called it, then you can just pass A as an argument. In other words, you define a consistent API where the @_ array always contains self and the calling object.

sub foo {
  my ($self, $caller, @targets) = @_;

  for my $obj ( @targets ) {
    $obj->bar($self, ... );
  }
}

sub bar {
  my ($self, $caller, @args) = @_;

  ...
}

The examples above don't do anything with $caller, but you can see how $self is included as an argument to the bar method call.

For a real-world example of this kind of thing, look at POE, which defines array-offset constants to pick out specific objects that are always passed as arguments. For example:

  sub handle_event {
    my ($kernel, $heap, $parameter) = @_[KERNEL, HEAP, ARG0];
    ...;
  }

It seems a little clunky at first glance, but when used consistently across all POE modules, it actually starts seeming elegant.

[Bloodnok]

TFT xdg,

Using defined offsets into arrays/lists, to my mind, has little to offer over the normal positional arg passing - if nothing else, AFAICT, PBP recommends avoidance of such measures. Personally, however, I prefer named args for long arg lists (as does PBP;-).

But thanx anyway for the reference - POE provided some interesting reading...

[xdg]

Using defined offsets into arrays/lists, to my mind, has little to offer over the normal positional arg passing

As I understand the idea in POE, one reason for it is forward compatibility. You can rearrange the order of positional arguments -- e.g. insert new ones between fixed arguments and a variable list of arguments at the end -- and since the constants are redefined at the same time, code using the defined offsets still just works.

IMO, PBP should be taken with (several) grains of salt. It's only one opinion about best practices and even the author says it's not an exclusive list of best practices. And there are some stunningly bad recommendations in there, too.