No, you don't copy the class. The class constitutes instructions to make an object, and the object is made from those instructions. An object is not a copy of the class, but an implementation of what the class represents.
Biniman Idugboe wrote:. . . Before now, I thought that creating an instance of a class decouples the instance from the class; something like making a copy of the class without modifying the class.
You mean the class has been designed to be immutable? So you have a word count with value 3 and you count another word and you get another object with the value 4. Does that answer your question about where instance fields are stored? Can't you see that line 30 creates a new counter object?
. . . Their actual values are supplied while instantiating the class. . . . are final fields final in the class or final in the instance of the class?
Of course the relationship between a class and its instances is unbreakable. The class determines the structure of the object and changes to the code in the class may cause the program to faill: serialisation and deserialisation is the one example that springs to mind.
A related question: Is the instance of a class independent of the class or are there underlying unbreakable connections between a class and its instances?
Static fields and static methods on my mind!
But a final field doesn't have a default value. Default values only apply to ordinary fields, not to all ints.
Biniman Idugboe wrote:. . . If the default value of an int is zero . . .
Biniman Idugboe wrote:
So, is counter + 1 effectively equivalent to previousInstance.counter + 1 ?
The previous instance passes its current value to the constructor . . .
It appears you believe that the counter identifier in this snippet of code refers to the field of the new object. It doesn't.
No, I said that unlike ordinary fields, it does not have a default value, not even 0/false/null. That is why the Java® Language Specification (=JLS) says,
Biniman Idugboe wrote:Are saying that a final field does not have initial value? . . .
Non‑final fields do not have to be definitely assigned to because they have default values.
A blank final instance variable must be definitely assigned and moreover not definitely unassigned at the end of every constructor . . .
when you first call filter() and then call map(), the tryAdvance() method of the spliterator associated with map() will create an action that represents the mapping operation,
and pass it to the tryAdvance() method of the spliterator associated with the filter() operation . . .
Biniman Idugboe wrote:In the illustration above, the Collection encapsulates the spliterator. So, the fields and methods of the collection are visible to the spliterator. Can we say that the collection wraps the spliterator? Could you also illustrate how, for example, a map() method becomes a spliterator, that is, how a spliterator wraps a map() method?
Biniman Idugboe wrote:At what point does the map() method invoke the spliterator() method of threethings?
Biniman Idugboe wrote:Also, I am confused about the consumer supplied to the tryAdvance() method. Where is that coming from (what is supplying it)?
Biniman Idugboe wrote:The MappingSpliterator is enclosed in the map() method. I am thinking that when the map() method is invoked, the codes inside its body are executed.
But all the methods of MappingSpliterator are instance methods, right? Are these methods going to be invoked? Invoked on what?
In the statement in line 44:
What is supplying the spliterator?
At what point is the tryAdvance() method invoked?
Don't count your weasels before they've popped. And now for a mulberry bush related tiny ad:
Two software engineers solve most of the world's problems in one K&R sized bookhttps://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton