Considering that Data::Dumper is entirely regular in how it will
present a deconstruction of the data structure, and you have a clear
concept of how you wish the example structure ===> accessor set thing
to work, it's certainly possible, and would take maybe two hacking
sessions to get right (provided you don't get swept into the lake by a
mini-tsunami.)
It seems like something that might not exist already, as the need to
share that kind of meta-abstraction is felt by only extreme show-offs
(such as various people on this list)
To make your example DWITYM, Data::Auto::Objectify::Thing would presume that
the structure returned by its caller has a C<new> that will return a
fully populated example object when called with no arguments, and
would postpone defining the accessors until the INIT phase, because
the &{caller()::'new'} does not exist yet at C<import> time.
I would have Data::Auto::Objectify::Thing take an optional C<< example
=> ... >> import arg in addition to the wait-until-INIT trick, and
would bless the substructures into constructed-named packages under
Data::Auto::Objectify::Thing::Packages::... for example.
Tipjar::fields creates accessors for named fields by imposing array
object semantics on its calling package; recently I prefer to use
:lvalue subroutines for accessors rather than defining both get* and
put* s.
In your example, you are planning on subclassing MyFoo into a whole
family of kinds of hash-based objects that share this accessor set, or
something. It's not clear if the elements are supposed to be
extensible or not. If they aren't extensible, and there is a fixed
set of them, using an array-based object and naming all the slots with
lvalue accessors is the way I would do it
sub new { bless [], shift };
BEGIN{
my $counter = -1;
eval join '' map {$counter++; <<ACCESSOR} (qw/one two three eat sleep/)
sub $_ : lvalue { shift()->[$counter] }
ACCESSOR
};
but of course I don't know exactly what you are trying to do.
