From: Ben Tilly <ben_tilly@...>
Date: 2001-01-09T23:18:04+09:00
Subject: [ruby-talk:8926] Re: No :<, :>, etc. methods for Array

Aleksi Niemel� <aleksi.niemela@cinnober.com> wrote:
>
>Hello,
>
>At least David Alan Black and Ben Tilly have been conversating, the 
>latter's
>last comment being:
>
> > 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.
>
>Ok. I've been following this thread with great interest, but I've been
>somewhat lost. That's mostly due to my quite limited knowledge of Perl 
>Tying
>concept. I always thought it's quite simple, but it's referred everywhere 
>as
>pure magic. Now I guess I got on the map again.

It is a simple magic. :-)

Imagine a language where you are constantly telling the
language everywhere that you have a duck because it is
walking like a duck and talking like a duck.  This is
built into everything that you do.  Then suddenly you
find out that it isn't really a duck after all.

What happened?

Magic!

(They even call it that in the source-code.)

In Ruby there is no surprise.  All that walking and talking
like a duck means is that you have the methods that a duck
does.  In Perl there is great surprise because you have
just violated (in a useful way, but still) a basic pattern of
how the language works.

>So if I understand correctly we would like to have (sorry being wordy, I
>just wanted to be clear):
[...]
>And then our current hash and all user defined hashes could be done by
>saying:
>
>   class HashAlike
>     include StandardHashInstanceMethodInterface
>     # and by defining 6 or 7 methods the interface *requires*
>
>     include Enumerable
>     # and by redefining methods for speed if needed
>     # like include? for Hash
>
>     include StandardHashConvenienceInterface
>     # and by redefining methods for speed if needed
>   end
>
>Ben, is this explicit separation and grouping of methods to interfaces
>(which might be expressed by default in terms of other interfaces) what you
>have in mind?

Yes.

>If so, then we might proceed to define interfaces for Strings and Arrays,
>and what else needed.
>
>If I understand the underlying concept correctly, by imposing some more
>structure to current classes, and keeping eye on backwards compatibility, 
>we
>ease up documentation of current behaviour and implementation of user made
>FooAlike -datastructures. If we get Perl's TIE behaviour as a bonus, this 
>is
>surely the way to go.

You understand exactly.  Getting Perl's tie behaviour is
not really a bonus.  It is good advertising which takes
advantage of the fact that few Perl programmers actually
understand anything about tie other than the fact that it
looks like magic and is a cool feature.

>This discussion reminds me of the recent String as IO (or the otherway
>round) thread. IIRC, the end result was that the APIs should be defined 
>more
>clearly and then masquerading classes to act like other classes would be
>trivial. Aren't we approach that solution?

Exactly.

However Strings in particular may be a special case.  We
might want to resolve whatever to a string for some things.
(Specifically when used as hash keys and when someone tries
to match against them.)

One note.  A good deal of Ruby's current library is
designed after how Perl works.  For scripting I think that
this is an excellent choice.  So even though it should be
easy to imitate a built-in class, IMO the built-in classes
should continue to have rich interfaces.

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