in reply to Re^10: Beyond Inside-Out
in thread Beyond Inside-Out

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.

-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.

Replies are listed 'Best First'.
Re^12: Beyond Inside-Out
by clinton (Priest) on May 30, 2007 at 19:08 UTC
    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.

    Agreed. I would say that by using a module from a plugin, you're joining what "should" be two black boxes, and those black boxes should interact via their API, and if you ignore encapsulation, then here be dragons.

    What happens if the internals of the plugin change, or the internals of the module? This would be the same issue regardless of the object model.

    That said, I'm sure that there are many modules that do exactly this, the authors probably wanting to save the expense of a method call, but I think it is Alter that is in the right here, and the plugin in the wrong.

    clint