>
For efficiency sake, Objects are passed to functions NOT by their value but by reference.What that means is that functions will not pass the Object, but instead pass a reference or pointer to the Object.
This is confused garbage, and goes rapidly down hill from there.
Reference semantics is required for OOP. The reference is necessary because that is the object. The object's "value" is a concept from the record or structure types of non-OOP languages like C and Pascal. If we pass the value, we are not passing the object, but a copy.
In high level languages, we don't even see the reference as a separately declared reference type; that is a low-level concept from "Blub OOP".
I'm surprised this blogger's Smalltalk experience didn't set him straight.
> If an Object is passed by reference to an Object Constructor, the constructor can put that Object reference in a private variable which is protected by Encapsulation. But the passed Object is NOT safe! Why not? Because some other piece of code has a pointer to the Object, viz. the code that called the Constructor.
The charitable way to understand this bizarre nonsense is that because the caller of the constructor has a reference to the object, it has access through the reference to the object's "value", and by going through that reference, it should be understood as bypassing the encapsulation of the container which also holds that reference as a private variable.
This is laughably confused. Encapsulation means just that the binding is private: the newly constructed object holds that existing object in a private slot. Encapsulation doesn't mean that the embedded/aggregated object's contents are also private to the aggregator. Those are protected by that other object's class!
> The Constructor will have to Clone the passed in Object.
Only in some very specific circumstances when it is necessary for this parent object to have its own instance of an object similar to the one which is passed in: either so that it can mutate this instance without having an effect elsewhere, or else so that it has a snapshot facsimile of the passed object which is immune from changes elsewhere.
Such a requirement doesn't always apply.
> So much for efficiency.
When such a requirement doesn't apply, the construction of the similar object or 'deep cloning' will not just be inefficient, but wrong. For instance container object will expect the contained object to react response to events, but instead it actually has a dead copy which isn't receiving calls from anywhere.
It's clear from the semantics whether "we want to be composed of that actual object" or "we want to be composed of a similar one, in a similar state to that one's current state".
The second situation may require planning and design work. Indeed, not objects can be easily copied.
Some other solution may be required, like splitting that object into some state that is easily copied and some part that remains shared. This need not even require a split, just a suitable copy operation.
Linux has clone() system call for processes with a bazillion flags to copy this and not copy that; kind of the same thing. Sometimes we share the address space and file descriptors and signal handlers, sometimes we don't.