The meaning of a = b in object oriented languages

The meaning of a = b in object oriented languages.

I just want to confirm that in OOP, if a is an object, then b = a is
only copying the reference.

(to make it to the most basic form:

a is 4 bytes, let’s say, at memory location 0x10000000 to 0x10000003

b is 4 bytes, let’s say, at memory location 0x20000000 to 0x20000003

in 0x10000000 to 0x10000003, it is the value 0xF0000000, pointing to
an object

b = a just means
copy the 4 bytes 0xF0 0x00 0x00 0x00 into 0x20000000 to 0x2000003
so that b now points to 0xF0000000 which is the same object.)

so essentially, a is just a pointer to an object.

and b = a just means that put that same pointer into b.

and that’s why in Python or Ruby, it is like:

a = {“a” : 1, “b” : 2}
b = a
a
{‘a’: 1, ‘b’: 2}

b
{‘a’: 1, ‘b’: 2}

a[“a”] = 999
a
{‘a’: 999, ‘b’: 2}

b
{‘a’: 999, ‘b’: 2}

so most or all object oriented language do assignment by reference?
is there any object oriented language actually do assignment by
value? I kind of remember in C++, if you do

Animal a, b;

a = b will actually be assignment by value.
while in Java, Python, and Ruby, there are all assignment by
reference. (“set by reference”)

Is that the case: if a is an object, then b = a is only copying the
reference?

Summercool wrote:

Is that the case: if a is an object, then b = a is only copying the
reference?

Yes, your understanding is exactly correct; C++ will assign by value
unless you explicitly use pointers, but the other languages will assign
by reference (except for primitive types).

Summercool [email protected] writes:

I just want to confirm that in OOP, if a is an object, then b = a is
only copying the reference.

Whether the language is OO or not has no bearing on this question. The
semantics of the assignment operator can and do differ between
languages, orthogonal to whether OOP is involved.

On Sep 17, 11:04 pm, Lloyd L. [email protected] wrote:

a, b is NOT changed as seen in the second print.

“different”
[“something else”, “bar”]

That means that there is a counter inside that says to separate the two
or b would have changed with a as a changed with b initially.

i think the line

a = “different”

means a is now set to a pointer to the String object with content
“different”.
or that “a is now a reference to the String object.”

and b is still a reference to the Array object. so that’s why a and b
print out different things. they point to different objects.

i think:

whenever in Ruby, Python, and Java,

a is never an object. a is always a “reference to an object”… this
will solve a lot of puzzles when we don’t understand some code
behaviors.

when a writing or a book reads “a is a Hash object; a is an Array
object; or a is an Animal object” it is just a short form to say that
“a is a reference to that object.”

b = a means “whatever a is referencing to, now b is referencing it
too”.

so that’s why a[1] = “foobar” will change what b will display, but
a = “foobar” will not change what b will display. (because a[1] =
“foobar” says “what is a referencing? go there and change its
content that has the index 1” and when b goes there to see it, it is
also changed.)

SpringFlowers AutumnMoon wrote:

Is that the case: if a is an object, then b = a is only copying the
reference?

That and it adds a counter.

a = [“foo”, “bar”]
b = a
b[0] = “bite me”
p a, b

a = “different”
p a, b


In the first print, we get
[“something else”, “bar”]
[“something else”, “bar”]

showing that changing b changes a, as expected. However, if we change
a, b is NOT changed as seen in the second print.

“different”
[“something else”, “bar”]

That means that there is a counter inside that says to separate the two
or b would have changed with a as a changed with b initially.

Lloyd L. schrieb:

SpringFlowers AutumnMoon wrote:

Is that the case: if a is an object, then b = a is only copying the
reference?

That and it adds a counter.

I do not see the evidence of a counter.

a = [“foo”, “bar”]

that means, a points to the array object (with two elements).

b = a

Now b also points to the same array object as a.

b[0] = “bite me”

Element 1 (with index 0) get’s changed - and since a and b both point to
this array object, the changes are seen by both variables (a and b).

p a, b

a = “different”

Now - a points to another object (of type string) then b. That the whole
magic, i.e. no magic at all and no counter needed.

p a, b


In the first print, we get
[“something else”, “bar”]
[“something else”, “bar”]

showing that changing b changes a, as expected. However, if we change
a, b is NOT changed as seen in the second print.

b is NOT changed because we did not change b and we also did not change
the array object b points to.

“different”
[“something else”, “bar”]

That means that there is a counter inside that says to separate the two
or b would have changed with a as a changed with b initially.

This is not true. There is no need of any counter.

BR Phil

Summercool a écrit :

The meaning of a = b in object oriented languages.

Oups, reading the subject I thought it was a Xah Lee post.

:wink:

Laurent Pointal schreef:

Summercool a écrit :

The meaning of a = b in object oriented languages.

Oups, reading the subject I thought it was a Xah Lee post.

me too …


The saddest aspect of life right now is that science gathers knowledge
faster than society gathers wisdom.
– Isaac Asimov

Roel Schroeven

On Sep 18, 2007, at 1:50 AM, Russell Wallace wrote:

Yes, your understanding is exactly correct; C++ will assign by
value unless you explicitly use pointers, but the other languages
will assign by reference (except for primitive types).

I don’t think you can generalize assignment semantics. You have
to consider each language separately.

With respect to “primitive types” and Ruby, it isn’t necessary
to make exception for these types with respect to assignment
semantics. All variables hold object references and assignment
is always in terms of references. This is true for all objects
(including symbols, fixnums, true/false/nil).

The only thing special about Ruby’s ‘primitive’ classes is that they
behave such that identity is isomorphic to equality. That is to
say that a.equal?(b) if and only iff (a == b).

Gary W.

On 9/18/07, Summercool [email protected] wrote:

i think the line

a = “different”

means a is now set to a pointer to the String object with content
“different”.
or that “a is now a reference to the String object.”

Yes!

and b is still a reference to the Array object. so that’s why a and b
print out different things. they point to different objects.

Yes!

i think:

whenever in Ruby, Python, and Java,

a is never an object. a is always a “reference to an object”… this
will solve a lot of puzzles when we don’t understand some code
behaviors.

Yes, Yes, Yes!

content that has the index 1" and when b goes there to see it, it is
also changed.)

Exactly!

As a long-time observer and contributor to this forum, I’ve got to say
that this subtle distinction between variables and objects has tripped
up more than it’s fair share of newbies. It might well be the #1
stumbling block for many ruby learners. Not to mention other similar
languages.


Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

Roel Schroeven wrote:

Laurent Pointal schreef:

Summercool a écrit :

The meaning of a = b in object oriented languages.

Oups, reading the subject I thought it was a Xah Lee post.

me too …

Nah, this dude’s all right, so far. As if my opinion mattered.

Stay with it, Summercool. It’s what discussion groups are for.

Here’s why the reaction: cross-posting of computer-science-type essays,
something Xah Lee does. But he recycles all his decades-old crap and
really
doesn’t participate in the discussion. This isn’t that at all.

Summercool wrote:

when a writing or a book reads “a is a Hash object; a is an Array
object; or a is an Animal object” it is just a short form to say that
“a is a reference to that object.”

b = a means “whatever a is referencing to, now b is referencing it
too”.

so that’s why a[1] = “foobar” will change what b will display, but
a = “foobar” will not change what b will display.

You can’t do both in Java. Is a an array or a String? If a is a String
and b
is an array, then neither a = b' norb = a’ will compile in Java.

Java is a strongly-typed, compiled language which means it does more
static
type checking and thus would reject treating a as both an array and a
String.
In that environment the programmer must choose one or the other.

Otherwise what you say is exactly correct.

(because a[1] = “foobar” says “what is a referencing? go there and change its
content that has the index 1” and when b goes there to see it, it is
also changed.)

Speaking just of Java, it’s useful to distinguish a variable from an
object
(instance). As you point out, the variable represents a reference to
the
instance. The variable has a compile-time type in Java, which may be
different from the run-time type of the object, albeit compatible.

C++ is similar in this respect. Python and Ruby are more, shall we say,
flexible in their type systems.

Both jet liners and hang gliders have their uses, both are flight, and
neither
is really suitable for the other’s purpose.

Lew schreef:

Nah, this dude’s all right, so far. As if my opinion mattered.

Stay with it, Summercool. It’s what discussion groups are for.

Here’s why the reaction: cross-posting of computer-science-type essays,
something Xah Lee does. But he recycles all his decades-old crap and really
doesn’t participate in the discussion. This isn’t that at all.

I fully agree and I didn’t in any way mean to compare Summercool to Xah
Lee. My apologies to Summercool if anyone interpreted it that way.

It’s just that somehow the subject seems to follow the same template as
what I’ve become used to from Xah Lee. I almost skipped reading the post
because of that. Once I started reading it though, it became immediately
clear that it was not comparable to Xah Lee’s postings in any way, shape
or form.


The saddest aspect of life right now is that science gathers knowledge
faster than society gathers wisdom.
– Isaac Asimov

Roel Schroeven

Ben Finney wrote:

Summercool [email protected] writes:

I just want to confirm that in OOP, if a is an object, then b = a is
only copying the reference.

Whether the language is OO or not has no bearing on this question. The
semantics of the assignment operator can and do differ between
languages, orthogonal to whether OOP is involved.

true enough. the copy mechanism of a language that uses garbage
collection has no concept of an address … therefore can only copy the
reference.

On 9/18/07, Gary W. [email protected] wrote:

With respect to “primitive types” and Ruby, it isn’t necessary
to make exception for these types with respect to assignment
semantics. All variables hold object references and assignment
is always in terms of references. This is true for all objects
(including symbols, fixnums, true/false/nil).

True. In the case of immediate value objects (i.e. fixnums,
true/false/nil), the ‘reference’, what the MRI implementation refers
to as the C type definition value, is actually an encoding of the
unique value.

The format of value references to symbols has varied from
implementation version to implementation version.

The only thing special about Ruby’s ‘primitive’ classes is that they
behave such that identity is isomorphic to equality. That is to
say that a.equal?(b) if and only iff (a == b).

Actually that’s not really special, it’s true of any object which
hasn’t overriden Object#==

For example, consider:

a = Object.new

At first glance this might appear to be a pretty worthless object, but
its unique identity can be useful. For example, it can be used to
mark an unused element in a collection when nil is not considered an
unused value.


Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

Hi All

We have started a Open Source CMS Project based on Ruby on Rails . We
are looking volunteers for admin, developer, senior developer , web
Designer roles .

project name = The Great Ruby cms
(TGRCMS)

project page : http://rubyforge.org/projects/tgrcms/

Interested? Join us

Mail us at = dumpe2fs at gmail com

Cheers

Ajay Maurya

Q:      What do you get when you cross the Godfather with an attorney?
A:      An offer you can't understand.

On Wed, 2007-19-09 at 21:55 +0900, Gone S. wrote:

true enough. the copy mechanism of a language that uses garbage
collection has no concept of an address … therefore can only copy the
reference.

Not all garbage collectors are copying collectors. Mark/sweep is the
first one that leaps to mind as a non-copying one. Baker’s Treadmill is
another. You’ll find lots of other collectors detailed and pointed to
here: the Garbage Collection Page

On 9/19/07, Ajay M. [email protected] wrote:

project name = The Great Ruby cms

Cheers

Ajay Maurya

Q:      What do you get when you cross the Godfather with an attorney?
A:      An offer you can't understand.

Care to post details on why you think we need another Rails CMS and why
the
current ones (e.g. Radiant) are not sufficient?

Jason

2007/9/19, Ajay M. [email protected]:

We have started a Open Source CMS Project based on Ruby on Rails . We

What kind of CMS are you thinking of? Blog, e-commerce, portal, or
general purpose?

On 9/19/07, Michael T. Richter [email protected] wrote:

I’d claim that the presence of and particular implementation of a GC is
orthogonal to the relationship between variables and objects.

In some (many) GC implementations, the physical reference stored in a
variable IS an address, and immediate references like fixnums are
represented by using bits which must be zero in object addresses due to
alignment, (e.g. objects with storage must all be at an even address, so
if
the low-order bit is on then the reference is immediate).

Whether or not the GC copies is invisible to the programmer using the
language, this is analogous to the way virtual memory hides the physical
address from the programmer.

Having a GC doesn’t preclude copying at the language level, after all
that’s
what Object#dup does. Of course this shouldn’t be confused with
assignment
by copying semantics.

One of the things that having a GC does is to make reference semantics
safe
from many of the errors which can occur due to botched ‘manual’ memory
management. One can certainly implement reference semantics in, say
C++, by
using pointers. One reason that C++ style guides deprecate such
practice is
that the bookkeeping of pointer references to avoid either memory leaks
or
crashes due to dereferencing a stale pointer is very difficult to get
right,
and often more expensive than a garbage collector. So many C++ projects
adopt a style where objects are copied rather than passed by reference,
but
that itself has a cost.


Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/