The defined interface decides which property to access based on the caller() function. Importing a method into a namespace (e.g. via Exporter) only creates an alias to the original, so any functions called from the method see the original namespace as the result of caller().

Example: $obj is of class MyClass. Depending on whether ego() is called from a native subroutine of MyClass (bar)or an imported subroutine from Plugin (foo), ego() finds a different calling package -- and thus returns a different storage hash. In the example below, foo() and bar both serve as accessors to the name field -- but they store/access different underlying hashes for the same object.

use strict;
use warnings;
no warnings qw/once/;

package Alter;

my %data;

sub ego {
    return( $data{scalar caller(0)} ||= {} );
}

package Plugin;

sub foo {
    $_[0]->ego()->{name} = $_[1] if @_ >  1;
    return $_[0]->ego()->{name};
}

package MyClass;

*ego = \&Alter::ego;
*foo = \&Plugin::foo;

sub bar {
    $_[0]->ego()->{name} = $_[1] if @_ >  1;
    return $_[0]->ego()->{name};
}

package main;

my $obj = bless( \my $scalar, "MyClass" );

$obj->bar( "Larry" );
$obj->foo( "Damian" );

for my $m ( qw/bar foo/ ) {
    print "$m: ", $obj->$m, "\n";
}
[download]

Prints:

bar: Larry
foo: Damian
[download]

This would be reasonable behavior if MyClass was a subclass of Plugin and both classes defined a name field, but that isn't what's happening here.

But that's my point - by asking for foo() or bar() you're not asking for the same thing - the fact that they both use the key name to store their values internally is irrelevant.

foo is trying to violate bar's encapsulation by accessing the value directly. Instead it should be using the provided API.

clint

The if $obj is a MyClass object (with no superclasses), the call to $obj->foo is equivalent to MyClass::foo($obj).

Note that this has nothing to do with the package Plugin -- so why does ego->{name} in MyClass::foo go to a Plugin storage slot? Because the foo function was first compiled in Plugin.

Whether you think it's good design or not, importing functions from some other .pm file and using them as methods is a common practice.

Of course, 'regular' inside-out classes wouldn't allow a plugin to attempt this -- the imported function wouldn't be able to access the lexical hash storing the property and it wouldn't compile. A plugin would be forced to use the accessor API.

What Alter does isn't 'wrong' per se, it's just sufficiently different to what people are used to that it's another potential source of unexpected bugs.

Put differently, it's yet another object paradigm for Perl.

• Store data in the reference
• Store data in lexical storage keyed to the reference (or an index)
• Store data in references keyed to the package name that an accessor is first compiled in, regardless of the package name used to invoke an accessor.

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.