Austin Ziegler
5/9/2005 6:26:00 PM
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