Out on HF and heard nobody, but didn't call CQ? Nobody heard you either. 73 de N7GH
Don't call them atomics, but primitives. Remember that some actions on primitives, e.g. double multiplication, are not atomic.Les Morgan wrote:. . . Objects have references and atomics are values.
Are you sure about that? If you reassign s2, that leaves s1 unchanged.. . . if you change s2 = "Bob and Jim"; What happens to s1 is s1 "Bob and Jim" also, no, because s1 and s2 are only references to what ever you want to tell them they reference. OK, so what about if we say s1=s2+" is cool." because Strings are immutable, you didn't change the String that was referenced by s1 (go back to using our first s1 and s2, but you now have s1 references a new string "Your Sword is cool." and does not have any reference to s2 any longer. Notice s1 still references a String, but now what happened to s2? Nothing. s2 is still the same, but s1 has now been orphaned and is eligible to be garbage collected when Java gets around to it. . .
Junilu Lacar wrote:To better understand shallow vs deep copy, you need to see the effects of doing just a shallow copy vs doing a deep copy. That's the context that you're missing.
When dealing with primitives, you'll always get true copies, so there should be no problem there. An example of this is your Ninja.hitPoints field.
When dealing with object references, however, mutability of the object being referenced and copied plays a role in deciding whether a shallow copy or a deep copy is appropriate.
When you copy a reference to an immutable object, a shallow copy is sufficient. This applies to references like String and Integer and other the primitive wrapper objects, for example. These cannot be mutated or changed once they are created. An example of this is your Ninja.name field.
No surprises. This is what you'd naturally expect.
Are you with me so far?
It gets a little tricky when you are dealing with mutable objects though. Let's assume that Weapons is a mutable object. That is, after you create it, you can add or remove items from it. Let's just suppose you could do this:
Now suppose you only did a shallow copy of weapons:
Here you've only copied the reference. This means that you would have:
The Ninja objects grace and john refer to the same Weapons object. So if I were to add a new item to john's weapons, grace would see that change too! Surprise!
And if I remove an item from grace's list, that item would be removed from john's list, too:
These two surprises are because john and grace refer to the same mutable Weapons object. In essence, they share the same set of weapons.
If you do a deep copy instead, then you wouldn't get any surprises.
If your mutable objects contain mutable objects which contain mutable objects, etc. then "it's turtles all the way down" and you would have to do deep copies until you get to a point where you're copying immutable object references only. That's the only way you can avoid surprises like what I illustrated above.
Does this help?
Junilu Lacar wrote:Justin, I suggest you go through the Java Tutorials to understand the basics of object instantiation before you come back and try to understand the mechanics of copy constructors.
Justin Robbins wrote:
Junilu Lacar wrote:Justin, I suggest you go through the Java Tutorials to understand the basics of object instantiation before you come back and try to understand the mechanics of copy constructors.
I'd like to hear everyone's take on it though. I learn better through communicating about it.
Only in the case of primitives do you copy the actual value (42, 42.0, false, etc). In the case of reference types, mutable or immutable, you always copy the reference. The value "George" never lives inside the object; it lives on the heap like all other objects (beware oversimplifications). The object with that field keeps a record of the location of that reference.Justin Robbins wrote:. . . what I think I understood. Ok, so primitives, String & wrapper objects are always TRUE COPIES because they are immutable, . . . are we copying their references or the actual things themselves like int 42 and String "george"?
Not quite. A change to the object reference will change the state of one classWhen you change an object by reassigning it, you are dissociating the new object from all other objects. There is the risk that you are setting up two references to the same object:-That is not what usually happens; each Ninja has to sharpen their own Sword. You should arrange the methods to look like n1.sharpenWeapon() and if (n1.hasSharpWeapon())... Far better than my multiple dots aboveAnywho, the problem arises in copy constructors when the constructor is fed in mutable objects. Since they are mutable and tethered through a reference, a change made to the mutable object reference will affect the original, and vice versa.
Inside the current method, yes, you instruct the JVM to create an object with the new operator. The constructor is called immediately thereafter so as to make sure all the fields are correctly initialised. The JVM then finds the memory location where that object can be found (another oversimplification) and writes that memory location into the object's field. It is better not to let the fields be seen outwith the class, so they should have private access. But if you assign them in a set methodYou get a new reference to a different String under the title of name, and you assign that to the name field called this.name. You are replacing the old memory location/reference with a new one pointing to (probably) a different object. The old reference disappears into cyber‑limbo never to be seen again, unless you have a copy of that reference elsewhere,so when we write something like john.name and we assign it "John"; what exactly is this even doing? pretty fresh to programming.
So we create an object of class Ninja and name it john
The new keyword is an operator, the same way the + and − are operators. It has a particular type of operand, and it has to be used in a particular order. You write 1 + 2 not + 1 2 which is out of order (unless you are writing LISP). There might be languages where you write new Ninja grace = Ninja(john), but Java® doesn't work like that. The new operator followed by the class name creates the object. The () after the class name call that constructor, with whatever information you are passing as arguments. You can do several things with the reference which you know the JVM will return:-. . . . . .. . .
Junilu Lacar wrote:
Justin Robbins wrote:
The only thing that I think I'd need further explaination on is:
Yes. I think you are right. And congratulations on the cow for the effort you have put into this thread and for asking a slightly unusual and veru interesting question question.Justin Robbins wrote:. . . I think it finally makes sense now.
You are still going on about memory; it would be better to think, “Create a new object.”A copy constructor is a way to tell Java, "Hey, if another object is passed into an objects parameters then run the copy constructor" and then the copy constructor is what specifies certain things, specifically here it says to free separate memory for weapons.
Assuming the CC is written that way, yes.So anytime the CC is called it will create a separate memory for that object, so that no two "character" objects will share the same weapons object.
Do you really mean stipulation? You can write stipulations in the documentation comments or you can write instructions (=statements) in the body of the method/constructor.It creates separate memory for those mutable object instance variables, so we would also have to create a stipulation in the copy constructor for tools as well.
Yes. . . So overall, deep copying is a way of explicitly allocating memory for specific mutable objects of any "character" object when the CC is called. And we only have to explicitly point out those mutable objects, the immutables one can just be straight shallow copied so no need for extra typing or memory for them into the CC.
Consider the = operator as working from right to left. That statement means something like this:-The only thing that I think I'd need further explaination on is:
. . .
That's a pleasureThank you so much for your help it's opened my eyes about deep and shallow copying.
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime. |