Let me try to clarify exactly what's going on here. This is the basic concept of references, as implemented by many languages. When you create, say, "an array," that array-value is an anonymous memory-object, and in your code both a
and b
refer to the same object. The language uses some variation of "reference counting" to keep track of how many references exist, so as to know when values have been "orphaned" and can be garbage-collected.
This so-called "shallow copying" is very efficient and it is often exactly what is wanted. So, it's what these languages do by default.
When you create a "deep copy," you are consciously duplicating the anonymous memory-object. Now, a
points to one, and b
points to another object that is (at that instant in time) a snapshot of the first. A time-consuming process by comparison, and, of course, it allocates more memory. Now, changes made to one array will (of course) not be reflected in the other, since they are now two entirely distinct things. Since this is a less-common thing to do, the language provides some explicit way for you to designate that you want to do this.
Ruby ... PHP ... Perl ... ... ... almost everybody does something like this.
(And, en passant, let me also say that they implement "strong" vs. "weak" references. But, that's another story for another day.)
EDIT: This response is partially incorrect! Kindly note the correction that was subsequently made in the first comment attached to this post. (And, "thank you for setting me straight!") The key point ( and it IS a key point ...), has to do with what the anonymous memory-objects aforementioned might contain. (They might, themselves, contain "references." Arrays often do! So, you could wind up with "two separate memory objects" which refer to the same things. Ergo, even though they are, indeed, "two entirely separate objects," they still can conflict with one another when actually used in your program. (And, heh, have fun debugging such things.)