Object reference handle (like perl's reference to scalar)

ruby-talk
1

> In ruby, is there a way to get a handle of an object
reference? In
> perl, this is the \ operator:
>
> $x = 1; # \$x is a handle to change $x
> $a = [1,2,3]; # \$a-> [1] is a handle to change an element
in $a
>
> As far as I can tell, the closest that Ruby has to this is
a
> symbol. But, this only works for object references that
have an
> associated variable name. For example, there is no symbol
> associated with an element of an array (or hash).

What are you trying to do? There is no equivalent to what you
want
in Ruby, but in most cases, it's not necessary. A little bit
of
rethinking, on the other hand, is necessary.

I've have various ways I can do what I need. I just wanted to
see if I could do it the perl way.

There is no way to do the following:

  a = [1, 2, 3]
  x = a[1]
  x = 4 # a == [1, 4, 3]

Variables in Ruby are simply labels for object references.
They are
not objects themselves. In Ruby, variables are transient
names --
they are effectively "weightless" and take up no space
(effectively).

Ruby variables must at least take up the space of a pointer (32
or 64 bits) and I would also imagine an entry in a symbol
table. But, that space probably isn't tracked by
ObjectSpace/GC. Not tracking that space like an object is
probably the reason why you can't have a general reference to
an object reference like perl has.

In Perl and C-like languages, variables
themselves
take up space on the call stack and may refer to other places
on the
heap.

You are probably right about perl (treat variables like
objects), but C is more like ruby in this respect. In C most
variables are on the stack and thus transient. You can make a
reference to one of those variables (i.e. a pointer to
somewhere in the stack), but that space will become invalid
once the variable goes out of scope.

Instead of having a general one-size fits-all reference to an
object reference, you could make a new class for each type of
object reference within each class. Of course you'd want a
common store/retrieve interface to all of these. For example:

class Array

  def ref(*index)
    Ref.new(self,*index)
  end

  class Ref
    def initialize(a,*i)
      @a = a
      @i = i
    end
    def value
      @a[*@i]
    end
    def value=(v)
      @a[*@i]=v
    end
  end

end

Example:

a = [1,2,3]
x = a.ref(1)
x.value -> 2
x.value = 4
a -> [1,4,3]
y = a.ref(0..1) # reference to a slice!
y.value -> [1,4]
y.value = [6,5,4]
a -> [6,5,4,3]

I think you could do this with just about anything. Here is
the info you need for changing various object references:

* array element/slice: array, index (and length .. or range)
* string element/slice: string, index (and length .. or range)
* hash value: hash, key
* hash key: hash, key (changes)
* local variable: binding, symbol
* instance variable: object, symbol
etc.

This goes beyond what perl references do! perl can't do
references to array slices and references to hash keys!

It looks like I answered my own question...

Now, I think putting this type of thing in the libraries could
be quite useful. At a minimum, it would allow you to easily do
the pass-by-reference thing that I've seen several questions
on.

Discover Yahoo!
Find restaurants, movies, travel and more fun for the weekend. Check it out!
http://discover.yahoo.com/weekend.html

2

[...]

What are you trying to do? There is no equivalent to what you
want in Ruby, but in most cases, it's not necessary. A little bit
of rethinking, on the other hand, is necessary.

I've have various ways I can do what I need. I just wanted to
see if I could do it the perl way.

I'm not sure why.

There is no way to do the following:

a = [1, 2, 3]
x = a[1]
x = 4 # a == [1, 4, 3]

Variables in Ruby are simply labels for object references. They
are not objects themselves. In Ruby, variables are transient
names -- they are effectively "weightless" and take up no space
(effectively).

Ruby variables must at least take up the space of a pointer (32
or 64 bits) and I would also imagine an entry in a symbol
table.

Must they? I'm not sure of that. *Objects* in Ruby take up a certain
amount of space, but whether the various labels for those objects
take up any space at all is a different question -- and completely
irrelevant to the execution of Ruby.

But, that space probably isn't tracked by ObjectSpace/GC. Not
tracking that space like an object is probably the reason why you
can't have a general reference to an object reference like perl
has.

With solely an implementation perspective, you might be right.
However, Matz could have easily made that space accessible -- Perl
did it, after all -- and could have made it so that variables were
real objects. He chose not to. Variable names in Ruby are just
labels. How much space they take up is completely irrelevant.
Matz deliberately chose to stay away from Perl-like semantics here
because Perl references and C pointers are some of the largest
sources of errors in those languages.

In Perl and C-like languages, variables themselves take up space
on the call stack and may refer to other places on the heap.

You are probably right about perl (treat variables like objects),
but C is more like ruby in this respect. In C most variables are
on the stack and thus transient. You can make a reference to one
of those variables (i.e. a pointer to somewhere in the stack), but
that space will become invalid once the variable goes out of
scope.

No, C is not at all like Ruby in this respect. The transience of a C
variable is, to be quite honest, something of an irrelevancy. You
*can* take an address of it. If I declare:

  char* foo;

Yes, foo is a pointer to char, but I can still take the address of
foo (getting the pointer to the pointer). This cannot be done in any
way with Ruby. This is an undesirable thing in Ruby.

Instead of having a general one-size fits-all reference to an
object reference, you could make a new class for each type of
object reference within each class. Of course you'd want a
common store/retrieve interface to all of these. For example:

Sure, you can create a Ref class. If you look on ruby-talk archives,
you'll see several implementations in the past three years. However,
such an object is useless. It can't act as the object for which it
holds the reference. It won't report as the object for which it
holds the reference.

...

Now, I think putting this type of thing in the libraries could
be quite useful. At a minimum, it would allow you to easily do
the pass-by-reference thing that I've seen several questions
on.

No, it wouldn't (to either question: be useful, or allow
pass-by-reference). Ruby's semantics are pass-reference-by-value.
This is something that people who use Ruby just have to get used to.

That you can do what you've done in this and the next post shows
that Ruby is powerful -- but neither is useful to most (I'd argue
99%+ development cases). I have had little need for such an object
at all. (There's one case that I have in PDF::Writer where such a
reference would be mildly useful, but the reality of what I need to
do here is more the elimination of all instance variable use in what
I'm trying to do. And *that* is a different beast entirely.)

-austin

···

On 5/4/05, Eric Mahurin <eric_mahurin@yahoo.com> wrote:
--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

3

"Austin Ziegler" <halostatue@gmail.com> contended:

Sure, you can create a Ref class. If you look on ruby-talk archives,
you'll see several implementations in the past three years. However,
such an object is useless. It can't act as the object for which it
holds the reference. It won't report as the object for which it
holds the reference.

Why do you assert these things about any concievable Ref implementation?
Even my Ref implementation does act as the object for which it holds the
reference for all purposes except explicitly querying type and reference
reassignment. Surely it's entirely conceivable to have a reference object
whose only difference from the referenced object is that it responds to
deref and deref=?

(There's one case that I have in PDF::Writer where such a
reference would be mildly useful, but the reality of what I need to
do here is more the elimination of all instance variable use in what
I'm trying to do. And *that* is a different beast entirely.)

I'd be interested to hear a little more about this, as you've said this is a
sub-1% problem - it must be interesting.

Cheers,
Dave

4

"Austin Ziegler" <halostatue@gmail.com> contended:

Sure, you can create a Ref class. If you look on ruby-talk
archives, you'll see several implementations in the past three
years. However, such an object is useless. It can't act as the
object for which it holds the reference. It won't report as the
object for which it holds the reference.

Why do you assert these things about any concievable Ref
implementation? Even my Ref implementation does act as the object
for which it holds the reference for all purposes except
explicitly querying type and reference reassignment. Surely it's
entirely conceivable to have a reference object whose only
difference from the referenced object is that it responds to deref
and deref=?

I don't recall the problems mentioned, but Ref objects have been
mentioned in the past as problems. If anything does a class-based
check, then the Ref object will never have a chance (and, yes, I do
this in PDF::Writer some; not much, but some). More to the point, I
was looking at the CSV code the other day to help someone and we
saw:

  case foo
  when String
  when IO
  when ...
  end

(1) It doesn't work with StringIO. (2) It can't/won't work with a
Ref object, because you'd need to redefine Class#=== (or is it
Module#===) to get this to work right.

(There's one case that I have in PDF::Writer where such a
reference would be mildly useful, but the reality of what I need
to do here is more the elimination of all instance variable use
in what I'm trying to do. And *that* is a different beast
entirely.)

I'd be interested to hear a little more about this, as you've said
this is a sub-1% problem - it must be interesting.

It's a purity problem. Right now, when you render a SimpleTable, it
makes some modifications to bits of the data in the SimpleTable.
This makes it very fragile. You cannot write the same SimpleTable to
two different PDF files at the same time, because of this. If you
render a SimpleTable, you may get a slightly different result if you
render it again.

I've got a (broken) reimplementation that separate out these
variables into a RenderVars object (it could as well be an
OpenStruct, but this also lets me pull some methods out of
SimpleTable that are really only related to the RenderVars). Doing
this will let me get around the problem of calls like:

  _y, _height = __table_column_headings(_y, @data)

It's that place where a ref-object might be useful -- I update _y in
place rather than by reassignment at the end. But it's a small thing
in comparison to everything else that I do.

-austin

···

On 5/6/05, Dave Burt <dave@burt.id.au> wrote:
--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

5

"Austin Ziegler" <halostatue@gmail.com> conversed:

Surely it's
entirely conceivable to have a reference object whose only
difference from the referenced object is that it responds to deref
and deref=?

I don't recall the problems mentioned, but Ref objects have been
mentioned in the past as problems. If anything does a class-based
check, then the Ref object will never have a chance (and, yes, I do
this in PDF::Writer some; not much, but some). More to the point, I
was looking at the CSV code the other day to help someone and we
saw:

case foo
when String
when IO
when ...
end

(1) It doesn't work with StringIO. (2) It can't/won't work with a
Ref object, because you'd need to redefine Class#=== (or is it
Module#===) to get this to work right.

That's not even difficult.

class Ref
  def kind_of?(mod) __getobj__.kind_of?(mod) end
end
class Module
  def ===(other) other.kind_of? self end
end

My Ref module at http://www.dave.burt.id.au/ruby/ref.rb now tries to behave
as much like the referred-to object as possible. You above Module case
statement will work with Refs now, as will uses of respond_to? is_a?
kind_of? and class. A Ref will additionally respond_to a few unique methods
(ie deref, deref=).

(There's one case that I have in PDF::Writer where such a
reference would be mildly useful...

It's a purity problem. Right now, when you render a SimpleTable, it
makes some modifications to bits of the data in the SimpleTable.
This makes it very fragile. You cannot write the same SimpleTable to
two different PDF files at the same time, because of this. If you
render a SimpleTable, you may get a slightly different result if you
render it again.

I've got a (broken) reimplementation that separate out these
variables into a RenderVars object (it could as well be an
OpenStruct, but this also lets me pull some methods out of
SimpleTable that are really only related to the RenderVars). Doing
this will let me get around the problem of calls like:

_y, _height = __table_column_headings(_y, @data)

It's that place where a ref-object might be useful -- I update _y in
place rather than by reassignment at the end. But it's a small thing
in comparison to everything else that I do.

Obviously an OpenStruct (or even an Array) could do the job, but why not try
a Ref? It's see-through! (Except for assignment, you have to do ref.deref=)
Of course, it's not much different from a Struct.new(:deref).

Cheers,
Dave

···

On 5/6/05, Dave Burt <dave@burt.id.au> wrote:

6

"Dave Burt" <dave@burt.id.au> schrieb im Newsbeitrag news:am_ee.5577$31.897@news-server.bigpond.net.au...

"Austin Ziegler" <halostatue@gmail.com> conversed:

Surely it's
entirely conceivable to have a reference object whose only
difference from the referenced object is that it responds to deref
and deref=?

I don't recall the problems mentioned, but Ref objects have been
mentioned in the past as problems. If anything does a class-based
check, then the Ref object will never have a chance (and, yes, I do
this in PDF::Writer some; not much, but some). More to the point, I
was looking at the CSV code the other day to help someone and we
saw:

case foo
when String
when IO
when ...
end

(1) It doesn't work with StringIO. (2) It can't/won't work with a
Ref object, because you'd need to redefine Class#=== (or is it
Module#===) to get this to work right.

That's not even difficult.

class Ref
def kind_of?(mod) __getobj__.kind_of?(mod) end
end
class Module
def ===(other) other.kind_of? self end
end

My Ref module at http://www.dave.burt.id.au/ruby/ref.rb now tries to behave as much like the referred-to object as possible. You above Module case statement will work with Refs now, as will uses of respond_to? is_a? kind_of? and class. A Ref will additionally respond_to a few unique methods (ie deref, deref=).

Hm, and what do you do if you have to test for Ref objects?

(There's one case that I have in PDF::Writer where such a
reference would be mildly useful...

It's a purity problem. Right now, when you render a SimpleTable, it
makes some modifications to bits of the data in the SimpleTable.
This makes it very fragile. You cannot write the same SimpleTable to
two different PDF files at the same time, because of this. If you
render a SimpleTable, you may get a slightly different result if you
render it again.

I've got a (broken) reimplementation that separate out these
variables into a RenderVars object (it could as well be an
OpenStruct, but this also lets me pull some methods out of
SimpleTable that are really only related to the RenderVars). Doing
this will let me get around the problem of calls like:

_y, _height = __table_column_headings(_y, @data)

It's that place where a ref-object might be useful -- I update _y in
place rather than by reassignment at the end. But it's a small thing
in comparison to everything else that I do.

Obviously an OpenStruct (or even an Array) could do the job, but why not try a Ref? It's see-through! (Except for assignment, you have to do ref.deref=) Of course, it's not much different from a Struct.new(:deref).

I didn't follow this thread thoroughly, all I can say is that I personally haven't missed refs in Ruby until now. There are certainly things that speak in favour of your concept.

But there are also problems. Ironically some of them seem to be caused by the fact that you make a Ref behave like the original instance as much as possible. That way Ref usage is more implicit than explicit and this can lead to confusion or subtle errors due to aliasing (i.e. you think you got a copy of something and modify it and some other piece of code breaks because it was just a ref).

<soapbox>
It still might be worthwile, I just get the feeling that people try to stuff things from other programming languages into Ruby because they found them cute / useful / the only way to solve certain things in that language. IMHO programming languages are different for a reason and often it's much better to adhere to the old saying "when in Rome do as the Romans do"... :slight_smile:
</soapbox>

Kind regards

    robert

···

On 5/6/05, Dave Burt <dave@burt.id.au> wrote:

7

[...]

Obviously an OpenStruct (or even an Array) could do the job, but
why not try a Ref? It's see-through! (Except for assignment, you
have to do ref.deref=) Of course, it's not much different from a
Struct.new(:deref).

If _y were the only place this were an issue, I'd agree with you --
a Ref (perhaps even a WeakRef) might be better. But it's not -- and
I can gain other efficiencies once I go through the development time
again. (The table rendering code is a mess. The only reason it's
still a mess is that the major refactoring broke it worse.)

-austin

···

On 5/7/05, Dave Burt <dave@burt.id.au> wrote:
--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

8

My Ref module at http://www.dave.burt.id.au/ruby/ref.rb now tries to
behave as much like the referred-to object as possible. You above Module
case statement will work with Refs now, as will uses of respond_to? is_a?
kind_of? and class. A Ref will additionally respond_to a few unique
methods (ie deref, deref=).

Hm, and what do you do if you have to test for Ref objects?

variable.ref?

I didn't follow this thread thoroughly, all I can say is that I personally
haven't missed refs in Ruby until now. There are certainly things that
speak in favour of your concept.

But there are also problems. Ironically some of them seem to be caused by
the fact that you make a Ref behave like the original instance as much as
possible. That way Ref usage is more implicit than explicit and this can
lead to confusion or subtle errors due to aliasing (i.e. you think you got
a copy of something and modify it and some other piece of code breaks
because it was just a ref).

You're right about that. I prefer the new implementation:
  Ref = Struct.new(:deref)

<soapbox>
It still might be worthwile, I just get the feeling that people try to
stuff things from other programming languages into Ruby because they found
them cute / useful / the only way to solve certain things in that
language. IMHO programming languages are different for a reason and often
it's much better to adhere to the old saying "when in Rome do as the
Romans do"... :slight_smile:
</soapbox>

I don't think what I've done here is anything like that. The concept of a
reference here is just a wrapper or pointer, and it has to have a use. Sure,
it causes problems in C and Perl, and Ruby definitely offers more elegant
tools fo most of the problems that are solved in those languages with
pointers, but I'm coming from a Rubyist's perspective here, and all I'm
proposing is a new container, for a single object.

And I think Austin's PDF::Writer example is one case where it's useful (that
is, passing an object by reference into a method so the method can replace
the object).

Cheers,
Dave

9

"Dave Burt" <dave@burt.id.au> schrieb im Newsbeitrag news:HS2fe.5993$31.2330@news-server.bigpond.net.au...

My Ref module at http://www.dave.burt.id.au/ruby/ref.rb now tries to behave as much like the referred-to object as possible. You above Module case statement will work with Refs now, as will uses of respond_to? is_a? kind_of? and class. A Ref will additionally respond_to a few unique methods (ie deref, deref=).

Hm, and what do you do if you have to test for Ref objects?

variable.ref?

I didn't follow this thread thoroughly, all I can say is that I personally haven't missed refs in Ruby until now. There are certainly things that speak in favour of your concept.

But there are also problems. Ironically some of them seem to be caused by the fact that you make a Ref behave like the original instance as much as possible. That way Ref usage is more implicit than explicit and this can lead to confusion or subtle errors due to aliasing (i.e. you think you got a copy of something and modify it and some other piece of code breaks because it was just a ref).

You're right about that. I prefer the new implementation:
Ref = Struct.new(:deref)

<soapbox>
It still might be worthwile, I just get the feeling that people try to stuff things from other programming languages into Ruby because they found them cute / useful / the only way to solve certain things in that language. IMHO programming languages are different for a reason and often it's much better to adhere to the old saying "when in Rome do as the Romans do"... :slight_smile:
</soapbox>

I don't think what I've done here is anything like that.

I had to place that comment in some of these threads that I feel we're seing more and more recently. I probably didn't pick the most appropriate one... :slight_smile:

The concept of a reference here is just a wrapper or pointer, and it has to have a use. Sure, it causes problems in C and Perl, and Ruby definitely offers more elegant tools fo most of the problems that are solved in those languages with pointers, but I'm coming from a Rubyist's perspective here, and all I'm proposing is a new container, for a single object.

And I think Austin's PDF::Writer example is one case where it's useful (that is, passing an object by reference into a method so the method can replace the object).

Yuck, may well be. On a side note, the fact that ruby methods can return an arbitrary number of objects is a really great thing, that can also help with some of these replacement problems.

Kind regards

    robert

10

Hi --

I don't think what I've done here is anything like that. The concept of a
reference here is just a wrapper or pointer, and it has to have a use. Sure,
it causes problems in C and Perl, and Ruby definitely offers more elegant
tools fo most of the problems that are solved in those languages with
pointers, but I'm coming from a Rubyist's perspective here, and all I'm
proposing is a new container, for a single object.

And I think Austin's PDF::Writer example is one case where it's useful (that
is, passing an object by reference into a method so the method can replace
the object).

It's a bit misleading to call it "passing by reference". In Ruby, all
passing is by value. Many values happen to be references. If you
have a Ref object, and pass it to a method, you are passing it by
value-which-is-a-reference. That doesn't change, even if the object
itself is of a class called Ref or Reference or Pointer, etc.

I understand that when you then *do* something with that object, you
are manipulating a second object, in a manner that emulates non-Ruby
reference semantics. But still, as far as what's happening when you
call the method with a Ref argument goes, it's still business as usual
for Ruby.

David

···

On Sat, 7 May 2005, Dave Burt wrote:

--
David A. Black
dblack@wobblini.net

11

<soapbox>
It still might be worthwile, I just get the feeling that people try to
stuff things from other programming languages into Ruby because they
found them cute / useful / the only way to solve certain things in that
language. IMHO programming languages are different for a reason and
often it's much better to adhere to the old saying "when in Rome do as
the Romans do"... :slight_smile:
</soapbox>

"Dave Burt" <dave@burt.id.au> schrieb:

I don't think what I've done here is anything like that.

I had to place that comment in some of these threads that I feel we're
seing more and more recently. I probably didn't pick the most appropriate
one... :slight_smile:

There are two reasons I like these threads.

The first is that when Perl- or C- or Whatever-thinkers ask these questions
to this list, they will be exposed to the Ruby Way of solving a class of
problems, and helped to free their mind.

Secondly, Ruby's a great language to push around and mould to your own whim
as a programmer. It's a great language to create DSLs in. These interesting
hacks are not going to displace the Ruby Way, but they help expand my
thinking in a similar way to learning Ruby (where I learned to routinely use
closures and meta-programming).

... all I'm proposing is a new container, for a single object.

And I think Austin's PDF::Writer example is one case where it's useful
(that is, passing an object by reference into a method so the method can
replace the object).

Yuck, may well be. On a side note, the fact that ruby methods can return
an arbitrary number of objects is a really great thing, that can also help
with some of these replacement problems.

Heh, I think that's Austin's view, too. He seems to badly want to rewrite it
:slight_smile: Anyway, multiple returns are interesting. You get an extra container
there, too (My Ref is just an extra container). They're often quite
disobvious, and I'm sure there are cases where it would seem more obvious to
modify an argument "in-place", even though "that's not possible in Ruby".

Cheers,
Dave

···

"Robert Klemme" <bob.news@gmx.net> wrote:

12

"David A. Black" <dblack@wobblini.net> argued:

And I think Austin's PDF::Writer example is one case where it's useful
(that
is, passing an object by reference into a method so the method can
replace
the object).

It's a bit misleading to call it "passing by reference". In Ruby, all
passing is by value. Many values happen to be references. If you
have a Ref object, and pass it to a method, you are passing it by
value-which-is-a-reference. That doesn't change, even if the object
itself is of a class called Ref or Reference or Pointer, etc.

I understand that when you then *do* something with that object, you
are manipulating a second object, in a manner that emulates non-Ruby
reference semantics. But still, as far as what's happening when you
call the method with a Ref argument goes, it's still business as usual
for Ruby.

I think it's all business as usual for Ruby. It's very similar to passing in
an array with 1 element, then replacing that element. If the intention is
replacement of the object, I don't see how you distinguish those semantics
from "by reference" - the object itself (array or reference) is a reference.
Or more correctly, has a reference.

Let's call it "pass by Ref" then, where Ref is my name for the container.

Cheers,
Dave

···

On Sat, 7 May 2005, Dave Burt wrote:

13

Hi --

"David A. Black" <dblack@wobblini.net> argued:

And I think Austin's PDF::Writer example is one case where it's useful
(that
is, passing an object by reference into a method so the method can
replace
the object).

It's a bit misleading to call it "passing by reference". In Ruby, all
passing is by value. Many values happen to be references. If you
have a Ref object, and pass it to a method, you are passing it by
value-which-is-a-reference. That doesn't change, even if the object
itself is of a class called Ref or Reference or Pointer, etc.

I understand that when you then *do* something with that object, you
are manipulating a second object, in a manner that emulates non-Ruby
reference semantics. But still, as far as what's happening when you
call the method with a Ref argument goes, it's still business as usual
for Ruby.

I think it's all business as usual for Ruby. It's very similar to passing in
an array with 1 element, then replacing that element. If the intention is
replacement of the object, I don't see how you distinguish those semantics
from "by reference" - the object itself (array or reference) is a reference.
Or more correctly, has a reference.

What I mean is, for example, if you've got:

   def m(a); end

   x = "hi"
   a =

   m(a)

the mechanics and semantics of the sending of a to #m are not
connected to what a actually is (an array containing a reference to a
string). What your method does with the things it's passed doesn't
play a role in the passing sequence.

So if it's correct (as I think it is) to say that Ruby only does
pass-by-value, I would not want to cloud that by saying, "unless the
thing being passed is an object encapsulating someone's implementation
of a reference-like behavior, in which case we might as well call it
'pass by reference' because we're going to do reference-like things
with it." There's no actual such connection; what the object is used
for is completely separate from the question of Ruby's
argument-passing semantics.

Let's call it "pass by Ref" then, where Ref is my name for the container.

I guess, but then do we have to say "pass by Array"? :slight_smile:

David

···

On Sun, 8 May 2005, Dave Burt wrote:

On Sat, 7 May 2005, Dave Burt wrote:

--
David A. Black
dblack@wobblini.net

14

"Dave Burt" <dave@burt.id.au> schrieb im Newsbeitrag news:gobfe.6148$31.690@news-server.bigpond.net.au...

<soapbox>
It still might be worthwile, I just get the feeling that people try to stuff things from other programming languages into Ruby because they found them cute / useful / the only way to solve certain things in that language. IMHO programming languages are different for a reason and often it's much better to adhere to the old saying "when in Rome do as the Romans do"... :slight_smile:
</soapbox>

"Dave Burt" <dave@burt.id.au> schrieb:

I don't think what I've done here is anything like that.

I had to place that comment in some of these threads that I feel we're seing more and more recently. I probably didn't pick the most appropriate one... :slight_smile:

There are two reasons I like these threads.

The first is that when Perl- or C- or Whatever-thinkers ask these questions to this list, they will be exposed to the Ruby Way of solving a class of problems, and helped to free their mind.

I heartily agree here. But of course this needs some form of openness on both sides, careful listening and considering arguments. Pure evangelism doesn't help.

Secondly, Ruby's a great language to push around and mould to your own whim as a programmer. It's a great language to create DSLs in. These interesting hacks are not going to displace the Ruby Way, but they help expand my thinking in a similar way to learning Ruby (where I learned to routinely use closures and meta-programming).

Yes, of course. However there's a difference between building a DSL and modifying fundamental behavior of the language. The second approach is the one that arouses my suspicion.

... all I'm proposing is a new container, for a single object.

And I think Austin's PDF::Writer example is one case where it's useful (that is, passing an object by reference into a method so the method can replace the object).

Yuck, may well be. On a side note, the fact that ruby methods can return an arbitrary number of objects is a really great thing, that can also help with some of these replacement problems.

Heh, I think that's Austin's view, too. He seems to badly want to rewrite it :slight_smile: Anyway, multiple returns are interesting. You get an extra container there, too (My Ref is just an extra container). They're often quite disobvious, and I'm sure there are cases where it would seem more obvious to modify an argument "in-place", even though "that's not possible in Ruby".

Personally I prefer to not have in place modification. If you view a method as some kind of (mathematical) function, then there's an input and an output. Returning values via arguments (= input) feels a bit awkward to me. It has to be done in other languages because they don't provide multiple return values; unfortunately this can make code hard to read. But since Ruby actually has mutliple returns, I personally prefer to do it that way.

Kind regards

    robert

···

"Robert Klemme" <bob.news@gmx.net> wrote:

15

"Robert Klemme" <bob.news@gmx.net> said:

"Dave Burt" <dave@burt.id.au> schrieb:

[Multiple returns are] often quite disobvious, and I'm sure there are
cases where it would seem more obvious to modify an argument "in-place",
even though "that's not possible in Ruby".

Personally I prefer to not have in place modification. If you view a
method as some kind of (mathematical) function, then there's an input and
an output. Returning values via arguments (= input) feels a bit awkward
to me. It has to be done in other languages because they don't provide
multiple return values; unfortunately this can make code hard to read.
But since Ruby actually has mutliple returns, I personally prefer to do it
that way.

I agree - arguments = input, return value(s) = output generally makes stuff
clear.
That kind of simple function is a great idea most of the time, but there are
cases where the obvious thing (obvious -> POLS) is for a side-effect to
occur. Good examples of this in standard Ruby include Kernel::puts and
String::sub!

Cheers,
Dave

16

David = "David A. Black" <dblack@wobblini.net>

It's a bit misleading to call it "passing by reference".

Dave:
I guess I was using the phrase "pass by reference" to refer to the doing of
reference-like things inside the method rather than the actual semantics of
the call (which is obviously still a normal Ruby method call). My bad, or a
simple misunderstanding.

Dave:

Let's call it "pass by Ref" then, where Ref is my name for the container.

David:

I guess, but then do we have to say "pass by Array"? :slight_smile:

Dave:
Yeah, and foo(:name => :value) should be "pass by Hash", etc...

Maybe Matz can sign off this Official Terminology Change at the same time he
changes "meta/singleton/virtual class" into "sterile class"!

Cheers,
Dave

17

"Dave Burt" <dave@burt.id.au> schrieb im Newsbeitrag news:r%yfe.7162$31.4588@news-server.bigpond.net.au...

"Robert Klemme" <bob.news@gmx.net> said:

"Dave Burt" <dave@burt.id.au> schrieb:

[Multiple returns are] often quite disobvious, and I'm sure there are cases where it would seem more obvious to modify an argument "in-place", even though "that's not possible in Ruby".

Personally I prefer to not have in place modification. If you view a method as some kind of (mathematical) function, then there's an input and an output. Returning values via arguments (= input) feels a bit awkward to me. It has to be done in other languages because they don't provide multiple return values; unfortunately this can make code hard to read. But since Ruby actually has mutliple returns, I personally prefer to do it that way.

I agree - arguments = input, return value(s) = output generally makes stuff clear.
That kind of simple function is a great idea most of the time, but there are cases where the obvious thing (obvious -> POLS) is for a side-effect to occur. Good examples of this in standard Ruby include Kernel::puts and String::sub!

Where exactly to these return something to the caller other than the instanece itself? Note: I did not oppose side effects. I just don't like to return values via (changed) command line arguments. Of cours, if I have a method remove_all_occurrences_of_1(enum) then it's quite "obvious" that since all 1's are removed from the Enumerable the collection will have changed afterwards. But for that to happen we do not need to return "enum" somehow because the reference itself did not change. Hope that clarifies it.

Kind regards

    robert