• Post Reply Bookmark Topic Watch Topic
  • New Topic

overloading  RSS feed

 
David Starr
Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I believe I am following the execution flow, but when it gets to the part of printing "val" I do not yet fully understand the logic. I have numbered end of line comments (for most all flow) as to what I believe is happening.
Can you please explain what then happens to print "val" in simple terms?



Output to console:
no args
arg
val
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
David Starr wrote:Can you please explain what then happens to print "val" in simple terms?


You called the print() method.

This line:

is equivalent to this:
 
David Starr
Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you, that helps a little. I am familiar with that representation; I tested it, and it works.

However, I wrestle with the step by step flow of execution. Is there an example somewhere that you know of, that provides an example and explains to excess what is going on?

Looking at .print(); it goes to the print() method but since the argument of "arg" is already established within it, it then prints locally instead.

 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
David Starr wrote:
Looking at .print(); it goes to the print() method but since the argument of "arg" is already established within it, it then prints locally instead.


No idea what you mean by "arg is already established within it" or "it prints locally instead," but I think you may be overcomplicating it. There is no such thing as "printing locally", and there is no "instead."

That print() method will always do exactly the same thing: Print out the String object pointed to by this object's arg member varible.
 
Paul Mrozik
Ranch Hand
Posts: 117
Chrome Mac Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
David Starr wrote:Thank you, that helps a little. I am familiar with that representation; I tested it, and it works.

However, I wrestle with the step by step flow of execution. Is there an example somewhere that you know of, that provides an example and explains to excess what is going on?

Looking at .print(); it goes to the print() method but since the argument of "arg" is already established within it, it then prints locally instead.

At a time like this, I wonder if you wonder "where is this guy learning Java from, a bathroom wall?" I really wonder if I have some sort of learning disability. I have had chemistry, and physics in the past though, seriously.


Two things happen when you do this:



1. You first create a new PrinterClass object
2. You invoke the print() method on the object

You could have just as well written this as:



Oops, sorry Jeff - you've already said this.

Does that help in seeing what happens to "val"?

David, answer this question: What does this.arg=arg do?
 
David Starr
Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


As far as I know refers to the arg parameter in the line that has public PrinterClass(String arg)

And then ends up printing the string that is in the statement System.out.println("arg");
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
David Starr wrote:

As far as I know refers to the arg parameter in the line that has public PrinterClass(String arg)

And then ends up printing the string that is in the statement System.out.println("arg");



That line doesn't print anything.

It takes the value that's in the arg local variable and copies it to the arg member variable. That's all it does.

Do you understand the difference between local variables and member variables?
 
David Starr
Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Local is per immediate method, and member is per class.

So, is it this.arg (local) assigned to arg which is then passed to public String arg ?
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
David Starr wrote:Local is per immediate method,


and member is per class.


Close. Static member variables exist per class. Non-static member variables exist per instance.

So, is it this.arg (local) assigned to arg which is then passed to public String arg ?


No.



When we create a new Foo instance with that constructor, the constructor takes the value that was passed in the arg x (which is a local variable) and copies it into the member variable.
this.x is the member variable
x is the local variable.
 
Ashish Dutt
Ranch Hand
Posts: 172
Java MySQL Database Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
David Starr wrote:Local is per immediate method, and member is per class.

So, is it this.arg (local) assigned to arg which is then passed to public String arg ?


David, if your code is changed slightly as follows

You will notice that it now gives the output as

What this implies here is that usage of the reference "this" always refers to the currently executing object.
So in your code it first prints "no args" because the overriden default constructor is called. The control then passes to the overloaded Constructor PrinterClass(String arg) where it does the following;
a) It initializes and assigns the instance private variable arg the value of overloaded constructor argument
b) The execution control then prints "args" and it then prints the value of instance variable which now is "val"
c)After this, the execution control then invokes the method print which refers to the instance variable arg and whose value had been already set to "val"

I hope this explanation helps.
 
David Starr
Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If I could get through this transfer of control and execution flow, I believe I would make a huge stride towards understanding Java. I do not understand why this appears so difficult to me. When I believe I understand it in my mind, I then come to realize I was leaning on my own understanding vs. Java rules of execution. I really need to get through this, however, I still wrestle with it.

Is this one of the most difficult things to get? I need to overcome this barrier! It is not intuitive to me.
 
Ashish Dutt
Ranch Hand
Posts: 172
Java MySQL Database Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
David Starr wrote:Is this one of the most difficult things to get? I need to overcome this barrier! It is not intuitive to me.


hmmm well i just hum the lyrics to "I believe i can fly" whenever i come to a deadend when it comes to programming
I guess we all pass through this aisle of un-comprehension whenever it comes to learning a new language
What at the most i could suggest in this case is to make lots of small programs and practice with them because computer programming is mathematics, the more you practice the better you develop that "programmer sense"
 
David Starr
Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What you say helps. Why it helps is the fact that I need to play around and practice with this language; and to believe for the epiphany / moment of enlightenment / paradigm shift.

The thing that irritates me, is the need to do this in order to 'figure out' how the byte code is chewed up / bounced around and spit out. The need to take hours/days/months/years to keep 'querying' the compiler to teach me about itself. Why does it need to be Fort Knox and all lines of communication severed besides notes passed in/out via carrier pigeon speed and efficiency. Someone developed the compiler with rules that seem vague to understand. I need to take the initiation hazing time to query the compiler in order to be accepted into the club.

Thank you Ashish. I do not want to diminish the fact that you are indeed helping. While I can tell I am frustrated, I will keep pushing through this rough spot to hit the smooth glass of success.
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
David Starr wrote:If I could get through this transfer of control and execution flow, I believe I would make a huge stride towards understanding Java. I do not understand why this appears so difficult to me. When I believe I understand it in my mind, I then come to realize I was leaning on my own understanding vs. Java rules of execution. I really need to get through this, however, I still wrestle with it.

Is this one of the most difficult things to get? I need to overcome this barrier! It is not intuitive to me.


Is there some particular aspect of it that's confusing you? I really think you may be thinking it's more complicated than it is. As long as we're talking about a single-threaded app (which so far I think you are) it's pretty straightforward.

It starts in main, and then statements are executed in order, with control transferring to other methods in the order they're called and back to where we left off when they're done. Is it "nested" method calls that are giving you trouble, like foo(bar(baz()))? That follows basically the same rules as algebra--you have to execute what's in the most deeply nested parens in order to get its result before calling the method that's using that as an argument.

Other than that, the only sort of stick part for order of execution is maybe with constructors and class initializers and instance initializers, particularly where multiple levels of super/subclass are involved, but I don't think that's been the issue here.
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
David Starr wrote:The thing that irritates me, is the need to do this in order to 'figure out' how the byte code is chewed up / bounced around and spit out. The need to take hours/days/months/years to keep 'querying' the compiler to teach me about itself. Why does it need to be Fort Knox and all lines of communication severed besides notes passed in/out via carrier pigeon speed and efficiency. Someone developed the compiler with rules that seem vague to understand. I need to take the initiation hazing time to query the compiler in order to be accepted into the club.


Huh? I don't understand what you're saying here. One of Java's main goals since its inception has been simplicity. Granted, the language has gotten significantly more complex since the early days but overall it's still relatively simple.

Although the "hours/days/months/years" part is to be expected in any new endeavor: http://norvig.com/21-days.html
 
David Starr
Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That is the thing. It is both math and java mixed. If I knew what I did not understand, I could ask the right questions in order to understand it. Egg before chicken vs visa versa.

From my original code submission (lines 1 through 19), this is the way I understand the order of the flow of execution, line by line:
15, 16, 7, 8, 4, 5, (then it becomes hazy to me - perhaps 9, 10, 16, and 16 again).

------

I took the advice of Norvig, applied for a job using Scheme (NexJ specifically), they did not select me. Said I interviewed good, but fell flat on technical portion of interview. This would appear I am presently doomed to get into working entry level Java (as the scoffers that read this are now laughing).
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
David Starr wrote:
From my original code submission (lines 1 through 19), this is the way I understand the order of the flow of execution, line by line:
15, 16, 7, 8, 4, 5,


Yes, that's correct.

(then it becomes hazy to me - perhaps 9, 10, 16, and 16 again).


When a method (or constructor ends), we have to have noted where that method was called from, so we can pick up from there. In this case, when the no-arg constructor ends at line 6, we know (because we traced from the beginning) that in this case (not always) it was called from line 8. So we go back to line 8.

There's nothing else there to pick up after the this() call, so it's 9, then 10, which takes us into the println() method, but we're not tracing that right now, but if there was, we'd note that we came from line 10 here, and come back here.

Then the constructor ends, so we pick up where we left off when we called it--back to line 16. On that line, we see that there's a print() call being made on the result of what we just did. Since what we just did was new PrinterClass(...), that means we have an instance of PrinterClass, so we're going to call its print() method.

So it's 12, 13, then print() ends and it's back to where we came from--back to 16. Then we're done.




One way you might imagine it--or actually do it physically a few times until you really grok it--is to take a bunch of index cards. Write down the body of each method and constructor on one index card. Use whatever shorthand is convenient to keep from having to write out every single character. Use a pencil to tick off the lines you're executing. When you get to another method call or constructor invocation, get the card for that method and put it on top of the current card. Tick of the lines on this new card. When it calls a method, put that method's card on top. Keep building up the stack of cards as methods get called.

When a method ends, remove that card from the top of the stack. Pick up executing at wherever you last ticked something off on the card that just got exposed.

This may help you conceptualize how things flow, and it also happens to model pretty closely how the computer actuall executes your code. It maintains a stack, building it up as it calls methods, and popping items off the top as they complete. It doesn't put the whole method body on the stack the way you put your cards on. It just adds a pointer telling it where to go back to to pick up execution--kind of like if you built a stack of little slips of paper with card number and line number on each one.

I took the advice of Norvig, applied for a job using Scheme (NexJ specifically), they did not select me. Said I interviewed good, but fell flat on technical portion of interview. This would appear I am presently doomed to get into working entry level Java (as the scoffers that read this are now laughing).


Sorry to hear it didn't go how you hoped. Nobody's laughing at you though.
 
David Starr
Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Jeff. I am going to need to go back to some textbook examples on this, and/or go onto some topics that I understand better leading up to what is all going on with this example.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!