[ruby-talk:8887] Re: No :<, :>, etc. methods for Array

On Mon, 8 Jan 2001, Ben Tilly wrote:

> The idea of tie is to have a totally new implementation
> that happens to have a similar interface to something
> native.  Given that you want to have a new implementation,
> you cannot inherit from the existing one.  Therefore you
> either implement some minimal subset of the existing one,
> or else you do rewrite a lot of (admittedly not complex)
> methods.  Many of which exist to be syntactic sugar.
> 
> For new code you can just use the subset.  Where tie
> becomes very handy is when you want to take a large body
> of existing code, not have to look at it, but still
> temporarily replace the implementation.
> 
[me:]
> >I'm willing to be persuaded, just currently see this as a solution in
> >search of a problem.
> >
> It is the same problem that Enumerable addresses.  Turn
> building a complex and widely used interface into building
> a rather small interface.  Many of the methods that are in
> Array and Hash today are there as either syntactic sugar or
> for convenience.  Why not make it easy for others to reuse
> the convenience of that interface?

In principle that's fine -- laudable, even :-) -- I'm just not getting
exactly what you mean in practice.  A module called TieHash?  Tieable?
What would it consist of?  I keep coming back to the fact that, if I
wanted to write a program using hashish... ummm... hash-like syntax, I
would give my class a []= method, and so forth.  I'm not clear on what
would be gained by inheriting from TieHash or something like that.

In Perl there's a kind of middle layer, because you can't just define
STORE() and have an object know what to do.  You have to have
something like tie(), so that the line can be drawn, so to speak, from
the object through the syntax ($hash{x} = "whatever") to STORE().  I
suppose my question is: does all of that really even have to happen in
Ruby, given how malleable everything is?  In Ruby you *can* "just
define" these things.  The fact that []= is a method seems to me to
change the logic of tying completely.  

Or is that a separate issue?  Back to question 1: if you are
describing something along the lines of a Tieable module, what would
be in it?


David

-- 
David Alan Black
home: [e-mail]
work: [e-mail]
Web:  http://pirate.shu.edu/~blackdav