in reply to Re^7: In praise of Perl's object system.
in thread In praise of Perl's object system.

I agree. I tend to solve this problem by having a namespace just for methods (sometimes one namespace just for class methods and another just for object methods). Then I write my code in an implementation namespace that is not searched for methods where I can write utility subroutines or import stuff with no worries. A simple demonstration might include:

package Cone::Head; our $VERSION= '1.001_001'; use Cone::Head::code qw< new objectNamespace >; package Cone::Head::Object; use Cone::Head::code; # Imports all object methods (by default) 1;
package Cone::Head::code; # ... use Devel::NamedArguments qw< parseMethodArgs >; sub objectNamespace { my( $we )= @_; return $we."::Object"; } sub new { my( $we, %args )= parseMethodArgs(@_); my $me= init( \%args ); return bless $me, $we->objectNamespace(); } # $obj->init() will say: Can't locate object method "init" via package +... sub init { ... } ...

The main drawback I find with this scheme is that caller is woefully inadequate at introspection. A more useful version of caller would be able to tell me that Cone::Head::Beldar->newFromDB() searched for newFromDB() for the class Cone::Head::Beldar and found newFromDB() in parent class Cone::Head where it had been imported from Class::NiftyORM where it was originally called CreateObjectFromDB() but the code inside that method actually considers its default package name to be Class::NiftyORM::code. A situation simulated by the following code:

package Class::NiftyORM::code; sub Class::NiftyORM::CreateObjectFromDB { ... } package Cone::Head; *newFromDB= \&ClassNiftyORM::CreateObjectFromDB; package Cone::Head::Beldar; @ISA= qw< Cone::Head >;

So I'd like to be able to get the following information from something like caller:

- tye