David Alan Black <dblack / candle.superlink.net> wrote:
>
>On Mon, 8 Jan 2001, Ben Tilly wrote:
>
> > I have mentioned before, perhaps I should mention again.
> >
> > The right container modules would (when combined with
> > mix-ins) provide a complete equivalent to Perl's tie.
> > As things stand someone who wanted to write a version
> > of Hash or Array which was tied to disk through a dbm
> > library like Berkeley DB would need to reimplement a
> > lot of methods.
>
>True, but when you write STORE() and FETCH() and all that in Perl,
>you're also reimplementing a lot of methods.  One could argue the
>other way -- namely, that in Ruby, the basic mechanism for redefining
>methods is so powerful that *all* you have to do to get tie
>functionality is reimplement some methods.  They happen to be called
>things like #[]=, rather than STORE(), but they're already there.

I would not advocate using the names used in Perl.

>To put it another way: even a "naive" Ruby approach to creating a
>tied hash:
>
>    class SomeTiedHash < Hash
>
>      alias ....
>
>      def initialize(*n)
>        # do some stuff, open a file, whatever
>        super(*n)
>      end
>
>      def []=(k,v)
>        oldset(k,v)
>        @fh.puts "#{k}: #{v}".....
>      end
>
>    end
>
>does actually create a tied hash.  I'm not saying there are no
>possible reasons to do some modularization and so forth -- but I don't
>see any big obstacles or logjams to doing tied things already.
>
In your book I count 40 methods for hashes.  Matching the
full behaviour of arrays would be worse.

Tying out to the full behaviour takes a lot more work than
it needs to.  A few well-chosen modules could make this
much easier.

Cheers,
Ben
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com