From: "Thomas B." <tpreal@...>
Date: 2008-09-06T19:28:33+09:00
Subject: Re: Request: arguments by reference

Hello Pedro.

> This is obviously a "solution" but with considerable performance 
> penalty. It's like using C pointers to alter values, so if you need to 
> alter a pointer's value you have a pointer to a pointer and so on...

Well, of course there is some performance penalty, but I guess it is not 
that fatal. I don't know the actual implementation of accessors in Ruby, 
but I think that the time penalty could be really low, and the memory 
penalty can be reduced by encapsulating logical group of variables in 
one class (which should be done anyway). I think that if they decided 
not to include passing by reference in Ruby (and also in Java), then 
they had some good solution in mind, and this solution cannot be as bad 
as you paint it.

> For instance, if I call a method that calls another method to change the 
> value I need to encapsulate this two times, that is, I need to 
> encapsulate each time I call a function to allow it to alter the value.

Here I don't understand - you need to encapsulate the field only when 
you want to pass by reference, so if you have a variable, and a chain of 
method that you want to be able to alter its value, then you have to 
encapsulate it only once, and pass the encapsulating class to the chain. 
I suppose that this "modify pointer to the pointer" thing is not very 
often needed.

> Suppose a Ruby implementation where += behaves like 
> <<, the final result is the same so I guess this complies with Ruby 
> language specification (...)

It does not, as far as I know. You cannot redefine += and other /.?=/ 
operators in Ruby, so I think it is ensured that they do create a new 
variable.

I agree that somebody could redefine << so that it returns a new 
variable, but this is simply an example of a bad thing to do. It's like 
redefining the 'operator ,' in C++ - a very very bad thing to do, and I 
wouldn't use such a library that does so. So still I think there is 
always a way to tell an in-place changer from a const function easily, 
and for me the whole question doesn't seem to be a problem.

I can understand that you want passing by reference to be available as 
an option, but in my opinion it is not possible to do it without some 
very deeply going changes in the language. Surely the = sign should be 
left for creating a new variable, and as bare pointers are not allowed 
in Ruby, currently I don't have any good idea how pass-by-reference 
could be done. You would also have to control the lvalue capabilities of 
expressions, which doesn't have to be done currently. For example, what 
if I pass by reference an expression like a.b, where b is an accessor, 
or arr[x]? Will it change the original underlying variable, or will it 
raise an error? Error at compilation, or at runtime?

Also I think that in a well designed program, the situations where you 
need such behaviour would not exist. Of course performance is important, 
but I think that still the most important thing is the ability to create 
a nice, readable and structured code, so I would definitely choose 
encapsulating over changing the language.

TPR.
-- 
Posted via http://www.ruby-forum.com/.