On 19 Jun 2008, at 01:18, David Nicol wrote:
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.)
Yeah, I've been sort of passively thinking about how to do it for a
little while. I don't think it's too hard but I don't want to reinvent
the wheel.
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 was thinking the accessors would be completely dynamic - AUTOLOADed.
So creation of the data structure can happen at any time before you
start calling accessors.
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.
I wasn't thinking of making dynamic packages at all. See above.
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
I basically want to be able to create read only 'value' objects that
wrap a data structure that's created dynamically at runtime. A
concrete example: I've just written some code that parses a formatted
summary of memory usage for a server product. There are five named
metrics for each of around 30 named categories of memory usage. My
code just parses what it finds - it doesn't know any of the names
ahead of time and the names might change as the product evolves.
I'd like the object that falls out of the end to let me do e.g.:
print $mem->relay_buffer->allocations;
instead of
print $mem->get('relay_buffer', 'allocations');
which is how it looks at the moment.
--
Andy Armstrong, Hexten
