Pass by reference?

ruby-talk
21

Xavier Noria wrote:

Java is pass-by-value for instance (according to the JLS) and that test passes.

Could you point me to the exact locus?

Thx:
Szab

···

--
Parragh Szabolcs
e-mail: parragh@dayka.hu
web: parszab.nir.hu

22

Hi --
<snip>
That's a somewhat different point, though, having to do with variable
scope and (re)assignment semantics. What you're doing here
essentially is:

   a = "low"
   b = a
   b = "hi"
   puts a # low

That's going to happen whether a method call is involved or not.

David, it is not my fault that parameter passing by value has the same
semantics as reference assignment :wink: (it probably is what is happening
behind the scenes, a new reference is allocated and the formal parameter is
copied to it).
Do you see what I wanted to show?

Cheers
Robert

David

···

On 1/27/07, dblack@wobblini.net <dblack@wobblini.net> wrote:

--
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black\)
    (See what readers are saying! http://www.rubypal.com/r4rrevs.pdf\)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)

--
"The best way to predict the future is to invent it."
- Alan Kay

23

Code >>>>>

def modifying(a_param)
   a_param = "hi"
end

def modifying2(a_param=a_value)
   a_param = "hi"
end

def modifying3(a_param)
   a_param[0..-1]= "hi"
end

a_value = "low"
modifying a_value
case a_value
when "hi"
   puts "Passed by reference"
when "low"
  puts "Passed by value"
else
  puts "Passed away"
end

a_value = "low"
modifying2 a_value
case a_value
when "hi"
   puts "Passed by reference"
when "low"
  puts "Passed by value"
else
  puts "Passed away"
end

a_value = "low"
modifying3 a_value
case a_value
when "hi"
   puts "Passed by reference"
when "low"
  puts "Passed by value"
else
  puts "Passed away"
end

>>>>> Output >>>>>

Passed by value
Passed by reference

>>>>> EoE >>>>>

I would name it somehow "call by assignment of value to local variable", because the value of the actual parameter is assigned to the local variable used as a formal parameter.

except for "Fixnum" etc. this is a pointer to an object. I one changes the object itself, it will work like "by reference", otherwise only the local variable is affected, without having any effect to the outside world.

Wolfgang Nádasi-Donner

24

Code >>>>>

def modifying(a_param)
   a_param = "hi"
end

def modifying2(a_param=a_value)
   a_param = "hi"
end

def modifying3(a_param)
   a_param[0..-1]= "hi"
end

a_value = "low"
modifying a_value
case a_value
when "hi"
   puts "Passed by reference"
when "low"
  puts "Passed by value"
else
  puts "Passed away"
end

a_value = "low"
modifying2 a_value
case a_value
when "hi"
   puts "Passed by reference"
when "low"
  puts "Passed by value"
else
  puts "Passed away"
end

a_value = "low"
modifying3 a_value
case a_value
when "hi"
   puts "Passed by reference"
when "low"
  puts "Passed by value"
else
  puts "Passed away"
end

Output >>>>>

Passed by value
Passed by reference

EoE >>>>>

I would name it somehow "call by assignment of value to local variable", because
the value of the actual parameter is assigned to the local variable used as a
formal parameter.

except for "Fixnum" etc. this is a pointer to an object. If one changes the
object itself, it will work like "by reference", otherwise only the local
variable is affected, without having any effect to the outside world.

Wolfgang Nádasi-Donner

25

I probably should have chosen different variable names. I was trying to make the point, that you cannot change a variable in bar by assigning in foo.

Kind regards

  robert

···

On 27.01.2007 12:10, dblack@wobblini.net wrote:

Hi --

On Sat, 27 Jan 2007, Robert Klemme wrote:

On 27.01.2007 01:43, dblack@wobblini.net wrote:

Hi --

On Sat, 27 Jan 2007, Martin C. Martin wrote:

Phrogz wrote:

If you pass an immutable type by reference, does it make a sound?
Er, I mean...
If you passed an immutable type by reference, how would you know that
it wasn't passed by value?

Is there any way for the function you're calling to modify the value of the variable in the caller? Pass by reference can do that.

You can modify the object to which the variable refers:

  def change_me(obj)
    obj << "hi"
  end

  arr = [1,2,3]
  change_me(arr)
  p arr # [1, 2, 3, "hi"]

In this example, arr contains a reference to an array. In change_me,
obj contains another copy of the same reference, so you can use it to
manipulate and change the original array.

I still wouldn't call this pass by reference (see my earlier post in
this thread).

Absolutely right: Ruby uses pass by value - with references.

irb(main):004:0> def foo(x) x = 10 end
=> nil
irb(main):005:0> def bar; x = 20; foo(x); x end
=> nil
irb(main):006:0> bar
=> 20
irb(main):007:0>

I'm not sure that demonstrates the "values that are references" thing,
though. You're reassigning to x in foo, which creates a new local x;
but I think that's just part of the assignment semantics. Or are you
assuming that if pass by reference were involved, then assignment
would work differently?

26

dblack@wobblini.net writes:

Hi --

Hi --

Phrogz wrote:

If you pass an immutable type by reference, does it make a sound?
Er, I mean...
If you passed an immutable type by reference, how would you know that
it wasn't passed by value?

Is there any way for the function you're calling to modify the value of
the variable in the caller? Pass by reference can do that.

You can modify the object to which the variable refers:

  def change_me(obj)
    obj << "hi"
  end

  arr = [1,2,3]
  change_me(arr)
  p arr # [1, 2, 3, "hi"]

In this example, arr contains a reference to an array. In change_me,
obj contains another copy of the same reference, so you can use it to
manipulate and change the original array.

I still wouldn't call this pass by reference (see my earlier post in
this thread).

Absolutely right: Ruby uses pass by value - with references.

irb(main):004:0> def foo(x) x = 10 end
=> nil
irb(main):005:0> def bar; x = 20; foo(x); x end
=> nil
irb(main):006:0> bar
=> 20
irb(main):007:0>

I'm not sure that demonstrates the "values that are references" thing,
though. You're reassigning to x in foo, which creates a new local x;
but I think that's just part of the assignment semantics. Or are you
assuming that if pass by reference were involved, then assignment
would work differently?

*** NEWBIE WARNING ***

I'm entering this thread as it gives me a chance to test my own understanding.
My apologies if I've missed the mark!

I agree the example doesn't show pass by reference v pass by value. I think it
shows more about scope.

However, I think what he was trying to show was that if what was being passed
was the address of the variable in the callers environment, then changes to
what that variable pointed at would be seen in the callers environment as well.

i.e.

a = Array.new could look like this

···

On Sat, 27 Jan 2007, Robert Klemme wrote:

On 27.01.2007 01:43, dblack@wobblini.net wrote:

On Sat, 27 Jan 2007, Martin C. Martin wrote:

-------

a | ----------
----------->|Array Obj|
    > ----------

------- Addr = 1000
Addr = 0

Here 'a' holds the value 1000, the address of the array object. This value
(1000) is stored in location 0. 'a' points to the storage location. In C it
would be called a pointer, in ruby, its just a variable because yo don't have
anything else. some would say 'a' is bound to the address 1000, which is the
start location of an array object.

Some of this confusion about passed by value and passed by reference is due to
C and how it worked. In C, by default, things are passed by value, but you can
only pass 'simple/base' types. Passing by value has the disadvantage that it can
have considerable overhead as the data being passed has to be copied and you
cannot modify the data such that the modifications exist after the procedure
terminates - modifications are local to the procedure because you are operating
on a local copy.

However, what people often miss is that, depending on the implementation, most
of the time, even passing a reference involves a copy. However, as what you are
copying is the address of the storage location where the data is located, the
copy operation is independent of the size of the data being referenced - its
simply a copy of an address and all addresses are essentially the same size. As
you are copying the address of the storage location, you can reference that
location from within the procedure and any modifications you make would affect
that data in the callers environment as well.

Ruby takes a different approach to C. In ruby, all variables are really
references to objects stored somewhwere else. The overheads associated with
arguement passing are the same regardless of the size or type of object the
variable references - its just an address. This means the traditional C pass by
reference and pass by value doesn't really apply in Ruby (or languages like
Java). All that nasty C referencing and dereferencing is handled under the hood
and the only ones upset are those clever geeks who use to do all sorts of
amazing pointer arithmetic that would take us mere mortals hours to grok.

Now, back to Ruby and the issue of whether the arguments to a procedure are
truely pass by reference or pass by value. Essentially, I don't think the
concept really makes sense from the Ruby perspective. However, I guess it could
be argued that if ruby was pass by reference with respect to arguments, this
would mean it passes the reference (address) of the variable. In the above
example, this would be the address of a, which is 0. If it was pass by value,
it would pass a copy of its contents, which is 1000.

If arguements were pass by reference, changes to what the address pointed to
would be seen in the callers environment i.e. address 0 would point somewhere
else. If it is pass by value, changes to what the argument variable points to
will be lost once the procedure exits and returns to the calling environment
because the argument is a copy. so

a = Array.new ------> Address 0 holds the value 1000, the address of the array.
def foo(b)
  b = Array.new -------> b points to array object at address 2000 (new array obj)
end

If ruby was pass by reference, the address of a and b wold be the same i.e. 0.
If it is pass by value, it would be different.

If a and b have the same address (i.e. 0) then after foo(a), a will boint at
the second array object (ie. contain address 2000).

Again, in languages like Ruby and Java, the by reference v by value really
doesn't make much sense because variables all hold references to the data
rather than holding the data directly. Generally, as conceptually (with respect
to argument passing), it is convenient to think of Ruby arguments as pass by
reference, but if you want to be really technically accurate, its pass by
value.

So, how successfully has that been at muddying the water? Everyone now nicely
confused?

Tim

--
tcross (at) rapttech dot com dot au

27

Xavier Noria wrote:

Java is pass-by-value for instance (according to the JLS) and that
test passes.

Could you point me to the exact locus?

Sure, that's section 8.4.1 in the current edition[*]:

"When the method or constructor is invoked (§15.12), the values of the
actual argument expressions initialize newly created parameter variables,
each of the declared Type, before execution of the body of the method or
constructor. The Identifier that appears in the DeclaratorId may be used
as a simple name in the body of the method or constructor to refer to the
formal parameter."

-- fxn

[*] Java SE Specifications

28

Hi --

Code >>>>>

def modifying(a_param)
a_param = "hi"
end

def modifying2(a_param=a_value)
a_param = "hi"
end

def modifying3(a_param)
a_param[0..-1]= "hi"
end

a_value = "low"
modifying a_value
case a_value
when "hi"
puts "Passed by reference"
when "low"
puts "Passed by value"
else
puts "Passed away"
end

a_value = "low"
modifying2 a_value
case a_value
when "hi"
puts "Passed by reference"
when "low"
puts "Passed by value"
else
puts "Passed away"
end

a_value = "low"
modifying3 a_value
case a_value
when "hi"
puts "Passed by reference"
when "low"
puts "Passed by value"
else
puts "Passed away"
end

Output >>>>>

Passed by value

But you've broken the bindings. It's a whole new ballgame, as we say
here :slight_smile:

Passed by reference

I would say: a reference, passed by value.

EoE >>>>>

I would name it somehow "call by assignment of value to local variable", because the value of the actual parameter is assigned to the local variable used as a formal parameter.

except for "Fixnum" etc. this is a pointer to an object. I one changes the object itself, it will work like "by reference", otherwise only the local variable is affected, without having any effect to the outside world.

I consider the variable assignment semantics to be a separate matter.
For example:

   def x(a)
     a = "hello"
   end

Here, Ruby's rule is that the second a is a completely new binding,
and destroys the original binding. I don't think that has anything to
do with whether the first a is a reference or a value. In other
words, even if Ruby had pass by reference, I assume that a = "hello"
would still destroy the binding and create a new local variable.

(Of course, it's purely speculative, since it would be a completely
different language.)

David

···

On Sat, 27 Jan 2007, Wolfgang Nádasi-Donner wrote:

--
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black\)
    (See what readers are saying! http://www.rubypal.com/r4rrevs.pdf\)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)

29

May be it will be clearer to name an assignment "a = someobject" by what it really means: "Give a reference to object 'someobject' a name 'a' by definition". It's close to the ":=" used for definition in mathematics.

If one uses this "a" as a "reference to 'someobject'" as an actual parameter in a method call, it means, that the "reference to 'someobject'" is actually used in the method.

Clearly you cannot change "a", because you don't have access to this name "a" inside the method, but you can change the object "someobject" usually without any problems. If you change "someobject" this will have consequences for 'a', because the object ist changed, the reference is still the same.

Wolfgang Nádasi-Donner

30

Wolfgang Nádasi-Donner <wonado@donnerweb.de> writes:

Code >>>>>

def modifying(a_param)
  a_param = "hi"
end

def modifying2(a_param=a_value)
  a_param = "hi"
end

In both the above cases, you are creating new objects that are only pointed to
by the variable a_param. Initially, that variable is referencing the same
object as the argument passed to the call. Effectively, you are chaging what is
being referenced.

def modifying3(a_param)
  a_param[0..-1]= "hi"
end

this one is different. You are changing the value of the object that the
argument references. You are not changing what is referenced.

a_value = "low"
modifying a_value
case a_value
when "hi"
  puts "Passed by reference"
when "low"
puts "Passed by value"
else
puts "Passed away"
end

a_value = "low"
modifying2 a_value
case a_value
when "hi"
  puts "Passed by reference"
when "low"
puts "Passed by value"
else
puts "Passed away"
end

a_value = "low"
modifying3 a_value
case a_value
when "hi"
  puts "Passed by reference"
when "low"
puts "Passed by value"
else
puts "Passed away"
end

Output >>>>>

Passed by value
Passed by value
Passed by reference

EoE >>>>>

I would name it somehow "call by assignment of value to local variable",
because the value of the actual parameter is assigned to the local variable
used as a formal parameter.

except for "Fixnum" etc. this is a pointer to an object. I one changes the
object itself, it will work like "by reference", otherwise only the local
variable is affected, without having any effect to the outside world.

I don't think your example shows what you believe it is showing. However, to
some extent, this is because the pass by value and pass by reference is
irrelevant in a language like Ruby. What your example shows is the effect of
changing what a variable points to within a function compared to changing the
contents of what is pointed to, it doesn't really show differences in the
traditional pass by value/pass by reference sense. I would argue that in each
of the cases you have shown, the arguments are passed by value, but the value
being passed is a reference to an object. In the first two, you change that
reference, but as it was passed by value, it does not affect the callers
environment. In the third one, you are changing the object that is being
referenced and therefore the change is also visible to the calling environment.
However, the actual arguments were all passed by value.

Tim

···

--
tcross (at) rapttech dot com dot au

31

dblack@wobblini.net writes:

Hi --

Hi --

Phrogz wrote:

If you pass an immutable type by reference, does it make a sound?
Er, I mean...
If you passed an immutable type by reference, how would you know
that
it wasn't passed by value?

Is there any way for the function you're calling to modify the value
of
the variable in the caller? Pass by reference can do that.

You can modify the object to which the variable refers:

  def change_me(obj)
    obj << "hi"
  end

  arr = [1,2,3]
  change_me(arr)
  p arr # [1, 2, 3, "hi"]

In this example, arr contains a reference to an array. In change_me,
obj contains another copy of the same reference, so you can use it to
manipulate and change the original array.

I still wouldn't call this pass by reference (see my earlier post in
this thread).

Absolutely right: Ruby uses pass by value - with references.

irb(main):004:0> def foo(x) x = 10 end
=> nil
irb(main):005:0> def bar; x = 20; foo(x); x end
=> nil
irb(main):006:0> bar
=> 20
irb(main):007:0>

I'm not sure that demonstrates the "values that are references" thing,
though. You're reassigning to x in foo, which creates a new local x;
but I think that's just part of the assignment semantics. Or are you
assuming that if pass by reference were involved, then assignment
would work differently?

*** NEWBIE WARNING ***

I'm entering this thread as it gives me a chance to test my own
understanding.
My apologies if I've missed the mark!

I agree the example doesn't show pass by reference v pass by value. I
think it
shows more about scope.

However, I think what he was trying to show was that if what was being
passed
was the address of the variable in the callers environment, then changes
to
what that variable pointed at would be seen in the callers environment as
well.

i.e.

a = Array.new could look like this

-------
> a | ----------
> ----------->|Array Obj|
> > ----------
------- Addr = 1000
Addr = 0

Here 'a' holds the value 1000, the address of the array object. This value
(1000) is stored in location 0. 'a' points to the storage location. In C
it
would be called a pointer, in ruby, its just a variable because yo don't
have
anything else. some would say 'a' is bound to the address 1000, which is
the
start location of an array object.

Some of this confusion about passed by value and passed by reference is
due to
C and how it worked. In C, by default, things are passed by value

<snip>

Ruby takes a different approach to C. In ruby, all variables are really
references to objects stored somewhwere else. The overheads associated
with
arguement passing are the same regardless of the size or type of object
the
variable references - its just an address. This means the traditional C
pass by
reference

I think those statements were informal, but just for the archives C only
has pass-by-value.

Sometimes people think that, say, modifying an integer through a pointer
argument shows pass-by-reference. But it doesn't, the argument is the
pointer there, and is passed by value.

-- fxn

···

On Sat, 27 Jan 2007, Robert Klemme wrote:

On 27.01.2007 01:43, dblack@wobblini.net wrote:

On Sat, 27 Jan 2007, Martin C. Martin wrote:

32

>>>>> Code >>>>>

def modifying(a_param)
   a_param = "hi"
end

def modifying2(a_param=a_value)
   a_param = "hi"
end

In these two methods, the = sign is an assignment, which changes the
memory location of the lvalue to point to the object of the rvalue.

def modifying3(a_param)
   a_param[0..-1]= "hi"
end

This is actually a method call. It could also be written a_param.
=(0..-1, "hi") . So the difference is that in this example you are
actually calling a method on the object that a_param points to. This
is due to the syntactic sugar Ruby gives to the method named = which
in this case is defined on String. See Ruby-Doc.org: Documenting the Ruby Language
ruby-doc-bundle/Manual/man-1.4/syntax.html#assign

So in all three we are passing by value as you define it.

···

On Jan 27, 5:34 am, Wolfgang Nádasi-Donner <won...@donnerweb.de> wrote:

33

fxn@hashref.com írta:

Xavier Noria wrote:
    

Java is pass-by-value for instance (according to the JLS) and that
test passes.
      

Could you point me to the exact locus?
    
Sure, that's section 8.4.1 in the current edition[*]:

"When the method or constructor is invoked (§15.12), the values of the
actual argument expressions initialize newly created parameter variables,
each of the declared Type, before execution of the body of the method or
constructor. The Identifier that appears in the DeclaratorId may be used
as a simple name in the body of the method or constructor to refer to the
formal parameter."
  
Thanks a lot, I was curious about this official description for a while!

What I miss, however, is the explicit use of the "pass by value" expression. Bruce Eckel mentions in Thinking in Java, that both sides of the controversy have lots of propagators. Both the "everything is pass by value" theory, and the contrary one that he descrbes as:

"2. Java passes primitives by value (no argument there), but objects
are passed by reference. This is the world view that the reference is
an alias for the object, so you don't think about passing references,
but instead say "I'm passing the object." Since you don't get a local
copy of the object when you pass it into a method, objects are
clearly not passed by value. There appears to be some support for
this view within Sun, since at one time, one of the "reserved but not
implemented" keywords was byvalue (This will probably never be
implemented)."

What is suprising is the reference (:-)) to Sun in this context, if the JLS says otherwise.

Anyways, this is not a Java list, so sorry for beeing a bit offtopic -- I just hope it helps to show, there's a great mess of notions around this topic everywhere.

Bye:
Szab

···

-- fxn

[*] Java SE Specifications

--
Parragh Szabolcs
e-mail: parragh@dayka.hu
web: parszab.nir.hu

34

Your description seems to be okay, but forget "address" when dealing
with Ruby variables. It's not an appropriate concept and only muddies
the waters unnecessarily.

-austin

···

On 1/28/07, Tim X <timx@nospam.dev.null> wrote:

So, how successfully has that been at muddying the water? Everyone now nicely
confused?

--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
               * austin@zieglers.ca

35

Hi --

···

On Sat, 27 Jan 2007, Wolfgang Nádasi-Donner wrote:

May be it will be clearer to name an assignment "a = someobject" by what it really means: "Give a reference to object 'someobject' a name 'a' by definition". It's close to the ":=" used for definition in mathematics.

If one uses this "a" as a "reference to 'someobject'" as an actual parameter in a method call, it means, that the "reference to 'someobject'" is actually used in the method.

Clearly you cannot change "a", because you don't have access to this name "a" inside the method, but you can change the object "someobject" usually without any problems. If you change "someobject" this will have consequences for 'a', because the object ist changed, the reference is still the same.

Right -- I take that as the starting point -- but what I mean is that
the way the assignment/rebinding semantics work doesn't necessarily
pertain to the reference/value question.

David

--
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black\)
    (See what readers are saying! http://www.rubypal.com/r4rrevs.pdf\)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)

36

<snip>
I don't think your example shows what you believe it is showing. However,
to
some extent, this is because the pass by value and pass by reference is
irrelevant in a language like Ruby.

I could not agree less, very simply because the two sentences
* In ruby a variable is a reference to an object
* All parameters are passed by value
define the whole semantic of parameters passed to methods(1), no need for
fancy boxes (though that is always good)
or to look at the implementation (but I had a close look before making bold
statements like these;)

(1) and that within well accepted computer science jargon
<snip>

Tim

--
tcross (at) rapttech dot com dot au

Robert

···

On 1/28/07, Tim X <timx@nospam.dev.null> wrote:

--
"The best way to predict the future is to invent it."
- Alan Kay

37

When talking about Ruby variables, it is ALWAYS incorrect to refer to
a "memory location." It's not a concept that has any useful meaning in
Ruby. Ever.

-austin

···

On 1/28/07, Grant Hutchins <nertzy@gmail.com> wrote:

On Jan 27, 5:34 am, Wolfgang Nádasi-Donner <won...@donnerweb.de> > wrote:
> >>>>> Code >>>>>
>
> def modifying(a_param)
> a_param = "hi"
> end
>
> def modifying2(a_param=a_value)
> a_param = "hi"
> end

In these two methods, the = sign is an assignment, which changes the
memory location of the lvalue to point to the object of the rvalue.

--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
               * austin@zieglers.ca

38

dblack@wobblini.net schrieb:

Right -- I take that as the starting point -- but what I mean is that
the way the assignment/rebinding semantics work doesn't necessarily
pertain to the reference/value question.

I agree. reference/value came from the world before talking about objects. I remember in Algol60 somehow the wording "after 'integer i;' the variable 'i IS an integer".

We would never say that after writing "s = 'A Ruby String object'" the variable 's' IS a String object - it gives a name for a special String object, or references a special String object (see 1).

Wolfgang Nádasi-Donner

(1): This wording is is used from a German, who tries to find out the best English word for what in German will be called "benennt", or "bezeichnet". I don't know what wording is really good in English.

39

Hi--

dblack@wobblini.net schrieb:

Right -- I take that as the starting point -- but what I mean is that
the way the assignment/rebinding semantics work doesn't necessarily
pertain to the reference/value question.

I agree. reference/value came from the world before talking about objects. I remember in Algol60 somehow the wording "after 'integer i;' the variable 'i IS an integer".

We would never say that after writing "s = 'A Ruby String object'" the variable 's' IS a String object - it gives a name for a special String object, or references a special String object (see 1).

There's also the distinction between references and immediate
values... though as Robert K. said, most of the differences are
hidden from the programmer (like, there's no extra level of
indirection you have to explicitly do).

Wolfgang Nádasi-Donner

(1): This wording is is used from a German, who tries to find out the best English word for what in German will be called "benennt", or "bezeichnet". I don't know what wording is really good in English.

I think "betoken" is probably the closest etymologically to
"bezeichnen", but it's more archaic-sounding. "Designate" might be a
good match. (This is why we end up doing things like using
"reference" as a verb :slight_smile:

David

···

On Sun, 28 Jan 2007, Wolfgang Nádasi-Donner wrote:

--
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black\)
    (See what readers are saying! http://www.rubypal.com/r4rrevs.pdf\)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)

40

Hi--

> dblack@wobblini.net schrieb:
>
>> Right -- I take that as the starting point -- but what I mean is that
>> the way the assignment/rebinding semantics work doesn't necessarily
>> pertain to the reference/value question.
>
> I agree. reference/value came from the world before talking about
objects. I
> remember in Algol60 somehow the wording "after 'integer i;' the variable
'i
> IS an integer".
>
> We would never say that after writing "s = 'A Ruby String object'" the
> variable 's' IS a String object - it gives a name for a special String
> object, or references a special String object (see 1).

There's also the distinction between references and immediate
values... though as Robert K. said, most of the differences are
hidden from the programmer (like, there's no extra level of
indirection you have to explicitly do).

> Wolfgang Nádasi-Donner
>
> (1): This wording is is used from a German, who tries to find out the
best
> English word for what in German will be called "benennt", or
"bezeichnet". I
> don't know what wording is really good in English.

I think "betoken" is probably the closest etymologically to
"bezeichnen", but it's more archaic-sounding. "Designate" might be a
good match. (This is why we end up doing things like using
"reference" as a verb :slight_smile:

Designated is just fine, I do not know the verb betoken.

However I do not necessarily agree with the post, still thinking...

Robert

···

On 1/27/07, dblack@wobblini.net <dblack@wobblini.net> wrote:

On Sun, 28 Jan 2007, Wolfgang Nádasi-Donner wrote:

--
"The best way to predict the future is to invent it."
- Alan Kay