From: Austin Ziegler <halostatue@...>
Date: 2005-05-10T03:26:14+09:00
Subject: Re: RCR 304: reference/pointer concept

On 5/9/05, Eric Mahurin <eric_mahurin@yahoo.com> wrote:
> Here are a couple of things this might be useful for (I just
> put these in the RCR). I'm sorry I didn't provide something
> more concrete sooner. Regarding #2, I've used references to
> hash values many times to get better efficiency (in perl).
> i.e.

Premature optimization is the root of all evil, as they say. As
such, I consider any suggestion that this abominable form would
increase its value by adding "optimization" ... questionable. At
best. Suggesting that it's necessary/useful for large hashes is
questionable as hash lookups are supposed to be O(1) in any case.

If the hash lookup in Ruby is worse than that, then perhaps we need
a new hash implementation, not an abominable "ref" in the core.

> 1. pass-by-reference or pass an lvalue. From what I understand,
>    the way you would write/use a Ruby method that modified lvalues
>    right now, would be like this:
>       def byvalue(*args)
>         # read and modify args
>         args
>       end
>
        a, b, c = byvalue(a, b, c)

This is correct, with the modification that I've made above. This is
also the right way to do this, in Ruby.

> With references, you could do this:
>       def byref(*args)
>         # read and modify args[i][]
>       end
>       byref(ref{:a},ref{:b},ref{:c})

1. This is precisely the case that I think makes your misguided
   proposal abominable. This is precisely the case that should NOT
   be used, because it introduces -- as Robert Klemme pointed out --
   side effects to the method call that are not at all apparent.

2. This syntax, as well, is precisely the syntax that I think makes
   this proposal so disastrously ugly. Not only do I have to *call*
   the method differently (e.g., with "ref { :a }" etc.), but I have
   to access the provided values differently. All so that I can
   change the values "in place." Not exactly efficient for the
   developer, and genuinely fugly.

3. This would then encourage a poor programming style produced by
   people who have experience with languages like C, C++, and Perl,
   where you have to do this to do anything truly useful. Why should
   we carry over bad, broken programming habits to a cleaner
   language like Ruby?

> With this simple variable case, there isn't much advantage, but
> when you are dealing with something deep within an object, it
> can offer an advantage:

4. If you are dealing with something deep in an object and need to
   pass it that way for possible modification, then your design
   needs shifting. Sorry, but it's true. At a minimum, it should be:

    val, pos = method(a["hi"][3], io.pos)
    a["hi"][3], io.pos = val, pos

This is a bad RCR for a bad concept (for Ruby) and should be
withdrawn.

-austin
-- 
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca