David Alan Black <dblack / candle.superlink.net> wrote:
>On Mon, 8 Jan 2001, Ben Tilly wrote:
[...]
> > 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.

Say modules called ArrayInterface, HashInterface and
StringInterface.

If you want to use it you would have to write []= and so
on, but the so-on to get the whole interface would be much
smaller than it would be now.

For instance if Ruby settles on a native reduce() method,
well there is no need to write that method in every class
that wants to do something like an array, is there?

>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.

Look at the list of methods for widely used basic classes.

How many of those are really basic, and how many can easily
be written in terms of the rest?

Now I agree that telling Perl people that this is tie is
just advertising.  The design of Ruby makes it trivial.
The internal design of Perl does not.

>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?
>
You would not have a single Tieable module.

You would have modules for each class you wanted to emulate
that let you define a basic list of methods and get the
entire interface.  A class which wished to provide what
Perl folks would think of as a tied interface would just
implement the basic and obvious methods, then mixin the rest
of the interface.

Instead of calling a magic tie function that did deep and
magic things, you would call "new".

If you think that this sounds like a trivial idea, then you
probably understood it correctly.  This isn't a hard thing
to do.  It isn't a hard thing to support.  It isn't a deep
change to the language.

But I suspect it would be convenient.

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