Yes you're re-inventing things that Moose already solved, but only you can determine whether that is worth your time, because I do believe that there is room for improvement in all of Perl's object frameworks, and perhaps you enjoy exploring other options.
As to your question, Perl's packages are each a data structure which you can inspect using this notation:
my $pkg_stash= do { no strict 'refs'; \%{ $pkg_name . '::' } };
To clarify, that is a global hash variable whose name starts with the package name and ends with '::'. (Once you get a reference to that stash, you can turn strict refs back on and keep using it.) Inside that hash, each value is a Perl Globref (if you're unfamiliar with globrefs, see perldoc perlref) You can walk that tree of stashes to find out which packages have a variable defined in them. Beware that on some early versions of perl, it might be impossible to tell the difference between a $Package::Foo that is assigned undef vs. a $Package::Foo that was never declared.
It sounds like you might also have re-invented the inheritence tree, but the built-in perl way of doing that is with the @ISA list. Each package defines @MyPackage::ISA=(...) forming a tree (or directed graph, for multiple-inheritence). If you want to "traverse up the tree" checking for the first parent class to define a variable, you can use mro::get_linear_isa.
my $package_hierarchy= mro::get_linear_isa($package_name); for my $p (@$package_hierarchy) { if (...) # check whether package $p has the variable defined }
While you're at it, you should read the whole documentation of mro to understand the problem it solves, and decide whether you want to take advantage of that in your class system.
When you call methods on Perl objects, it very efficiently navigates the @ISA inheritance tree to find the method. Unfortunately, there is no built-in efficient navigation of @ISA to look for anything other than methods. So, you are stuck with the performance hit of iterating it with get_linear_isa *unless* you wrap access to those variables with methods. So, for a class system, this means that if you want derived classes to be able to inherit class variables from the parent, but also be able to re-declare them, you probably want to generate an accessor method. This way the end user calls a method and the hierarchy lookup is as fast as a method.
In your case, it looks like you want to modify derived classes from the parent class. This is the opposite direction from most of what I've described, but can make use of the same mechanisms. If you want 'configure' to be fast, it should probably just set options on the local class stash and let the attributes walk backward to find the inherited value. If you want attribute lookup to be fast, each attribute should be a generated method that reads a single package variable, and you should have a mapping of attribute name to all the derived classes that re-declare it, so that 'configure' can quickly update them all.
Hope that helps.
In reply to Re: Reconfiguration of classes in an "inheritable" manner
by NERDVANA
in thread Reconfiguration of classes in an "inheritable" manner
by Amblikai
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |