Re: Simple multi-level tie

On Wed, Dec 17, 2003 at 02:00:23PM -0600, Andrew Sterling Hanenkamp wrote: I would like the ability to store a complicated record inside of a DBM file. I looked in the usual places and perldoc -q DBM gives me: Either stringify the structure yourself (no fun), or else get the

Re: BTRIEVE::*

On Thu, Dec 18, 2003 at 03:49:07PM +0100, Steffen Goeldner wrote: I'm still open for namespace suggestions. The following list BTRIEVE::File BTRIEVE::ISAM::File BTRIEVE::ISAMFile BTRIEVE::IsamFile with descending preference comes into my mind. Assuming ISAM is implied by

Re: BTRIEVE::*

Steffen Goeldner wrote: I understand your objections because each (but the first) retrieval is based on a 'current record' - thus storing that state in a separate iterator object may be a better choice. I rejected that! The documentation says: Btrieve initializes the Position Block when

Re: Simple multi-level tie

On Thu, 2003-12-18 at 05:59, A. Pagaltzis wrote: I'd prefer if it didn't (ab)use the minus on literal string. There's nothing ambiguous in the syntax that might require it. I disagree, since the tie call could include -inflate_key and -deflate_value. It is also legal to say: tie %hash,

Re: Simple multi-level tie

On Thu, 2003-12-18 at 04:26, Tim Bunce wrote: I'd add a -1 to the split and not in the docs that the example won't handle undefs. Fine. The example is relatively close to what I need the package for, but as a general example it's probably a poor one. I didn't like it at first but the more I

Re: Simple multi-level tie

I would like to revise my original query into a proposal in light of the comments I've received to now suggest a Tie::Filter namespace for filtering Tie classes. There could be specialized classes Tie::Filter::Scalar, Tie::Filter::Array, Tie::Filter::Hash, and Tie::Filter::Handle. However, at

Re: Simple multi-level tie

Another question I want to add to my proposal is: should the code references work by modifying $_ in-place (as with DBM filters) or should the code take an argument and return a result. I think I lean towards the modification of $_ in-place as it seems a little more Perlesque. Cheers, Sterling

Re: Simple multi-level tie

Andrew Sterling Hanenkamp [EMAIL PROTECTED] wrote use Storable qw(freeze thaw); use Tie::HashWrapper; tie my %wrappee, 'AnyDBM_File', ...; tie my %hash, 'Tie::HashWrapper', \%wrappee, -inflate_value = sub { thaw(shift) }, -deflate_value = sub { freeze(shift) }; Or rather more

Re: Simple multi-level tie

* Andrew Sterling Hanenkamp [EMAIL PROTECTED] [2003-12-18 20:01]: I think I lean towards the modification of $_ in-place as it seems a little more Perlesque. Given the name Tie::Filter, I'd agree. -- Regards, Aristotle If you can't laugh at yourself, you don't take life seriously enough.

Re: Simple multi-level tie

* Andrew Sterling Hanenkamp [EMAIL PROTECTED] [2003-12-18 19:02]: However, at this point, this project is becoming far more serious than the original idea Which is always good when code's meant to go onto CPAN :-) The wrapped object must be of the same type as the tie itself since the

Re: Simple multi-level tie

On Thu, 2003-12-18 at 14:11, A. Pagaltzis wrote: I do, because for simple one-off uses, the standard mechanism requires too much baggage. Sometimes I'd like to use tieing in a 10-line script; not having to create a package and populate it with a half dozen subs, which is alone 15 lines of red

Re: Simple multi-level tie

On Wed, 2003-12-17 at 23:25, Andrew Sterling Hanenkamp wrote: tie my %hash, 'Tie::HashWrapper', \%wrappee, -inflate_value = sub { thaw(shift) }, -deflate_value = sub { freeze(shift) }; $hash{a}{complicated}[4]{data} = [ 'structure' ]; warning: the above will not autovivify.

Re: Simple multi-level tie

What I want to know is, is Tie::HashWrapper a good name? If you don't like that name, what might you call it? HashWrapper sounds kind of dorky to me, but that's what first came to mind and I didn't want to spend all day trying to name it, I wanted to play code monkey. Cheers, Sterling I

Re: Simple multi-level tie

On Thu, 2003-12-18 at 14:11, A. Pagaltzis wrote: I like them better as well, but I think (in|de)flate is too specific considering the generic nature of these filtering tie modules. I can't think of any better terminology of my own; maybe it would be best to simple reuse the names we're already

tie::late

thinking about the latestring and imagining that a late printf would also be useful. The general case would use closures instead of references, which means writing an anon sub in the tie. Something like package late; sub TIESCALAR { bless $_[1] } sub FETCH { $_[0] } __END__