>===== Original Message From Mathieu Bouchard <matju / sympatico.ca> =====
><rant>
>
???
>
>On Tue, 27 Mar 2001, Benjamin J. Tilly wrote:
>> - Perl's tie is being done in Ruby - right.  In Perl there is
                ^^^^^^^^^^^^^
>>   a basic syntactic wall between dealing with an object as an
>>   object and dealing with it as a drop-in replacement for a
>>   native data-type.  Ruby's syntax makes this a non-issue.
>
>Well, I haven't seen the "tie" feature in Ruby. You can't just call Ruby's
>syntax an implementation of "tie".

I did not say that it was done.  I said being done.  For a
reason.  I am well aware that, despite much hard work on
your part, it isn't done yet.  But when you are happy with
it, it will be better than what Perl has because you are
able to work with the language to extend it rather than
fighting the syntax.

>In Ruby there is a basic public relations wall between dealing with an
>object as an object and dealing with it as a drop-in replacement for a
>native data-type.

I am aware of that.  The point being that native data-types
have a lot of functionality that people take for granted.
A lot of that is syntactic sugar.  One of the things that
Perl's tie facility does - and the "only" thing you need to
do - is translate from a minimal internal interface from
which the richer visible one can theoretically be provided,
and the richer interface that people may expect to be there.

The other thing that is needed in Perl is low-level support
to translate from basic syntax to method calls.  This is the
part you *don't* have to do in Ruby.

>The Ruby community's standard lie is that you only have to define #[] and
>#[]=. This is from the people who have never really considered doing so.

I doubt that many who understand the original in Perl would
claim that.  Conversely most who claim that probably do not
understand the full power of the original.

>To implement those two methods you need to work out negative indices,
>slice by length (with negative indices), slice by range (with negative
>indices bypassing the semantics of range), expanding array with default
>value 'nil', handling out-of-bounds fetching, and if you are implementing
>String, you also have to handle slice by string and slice by regexp.
>And you have to raise errors when you need to. By the time you succeed you
>have filled a few pages, and that's only 2 methods.

Yup.

>Perl's "tie" is by all standards a hack. However, from a user's point of
>view, it _works_, and as an idea it _works too_. This is why I have
>written MetaRuby in the first place: to bring that idea to Ruby. And this
>is also why I am rejecting any requests to make MetaRuby "less like Perl".

Allow me to say it another way then.

When Larry Wall chose Perl's native data structures he chose a
small circle of ideas that play very well together for a wide
range of natural problems.  For each data type he put in the
ability to do many types of operations that people often want
to do.  Ruby largely lifted this design.

Therefore Ruby has a fairly small number of very rich native
data types.  Imitating those is a lot of work because of the
richness of the interface.  However that same richness is tied
to how convenient it is to use.  Look through the functionality
that is offered by Array, String, and Hash.  There is a lot of
meat there, meat that your programs use all of the time.  For
someone to build a new and interesting Array, String, and Hash
*AND* have them be able to transparently be used where the
current data types are used, all of that functionality needs
to be provided.

Sure, you can boil down everything that you do to a small
number of simple operations.  If existing Ruby code only used
the same limited operations, then matching the interface
would be easy.  But the interface exists because it is used,
and the syntactic sugar has value.

>But one thing MetaRuby can't do yet is make the delusions go away. I plan
>to add that feature around version 1.618034, and clearly I'm not there
>yet.

Perhaps a few more of these rants will help?

Cheers,
Ben