Win a copy of Serverless Applications with Node.js this week in the NodeJS forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Bear Bibeault
  • Jeanne Boyarsky
  • paul wheaton
Sheriffs:
  • Junilu Lacar
  • Paul Clapham
  • Knute Snortum
Saloon Keepers:
  • Stephan van Hulst
  • Ron McLeod
  • Tim Moores
  • salvin francis
  • Carey Brown
Bartenders:
  • Tim Holloway
  • Frits Walraven
  • Vijitha Kumara

I'm trying to get a better understanding of the "this" implicit parameter  RSS feed

 
Ranch Hand
Posts: 33
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Can someone clarify what this is used for?

Here is my understanding (flawed as it may be).

If there is a field variable with the same name as a member variable used within a method, using this can distinguish between the two,
and as a result, things are less confusing.

Am I understanding this correctly?

Is there a benefit to using this as opposed to just declaring a different variable name?

Thanks, and I apologize if this has been covered, I didn't see this specific question asked when I attempted a search.

Bill
 
Bartender
Posts: 694
10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Bill Platt wrote:If there is a field variable with the same name as a member variable used within a method, using this can distinguish between the two,
and as a result, things are less confusing.
Am I understanding this correctly?

Yes.

Bill Platt wrote:Is there a benefit to using this as opposed to just declaring a different variable name?


Not really, although this is a matter of personal taste.
Personally, I try not to create local variables with the same name as an instance or class variable. Just makes things simpler.
However, sometimes it is useful to do so. For example, for parameters of public methods, especially getters and setters, it can be useful to give them the same name as the instance variable (and therefore necessitating the use of "this" to distinguish which one you are referring to). That way the generated javadocs display the name to the reader.
 
Saloon Keeper
Posts: 2476
317
Android Angular Framework Eclipse IDE Java Linux MySQL Database Redhat TypeScript
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Bill Platt wrote:Is there a benefit to using this as opposed to just declaring a different variable name?


this is a reference to the instance itself.

It can also be use to call other constructors in the same class.  In this example, an alternate constructor is provided which uses a default value for message if not specified.  Rather than repeat the code to split the recipient in to username and domain fields, it is only done in one constructor, which is called by the other:

In this example, this is used to pass a reference of itself (an instance of a class which implements AlarmListener) to another class:
 
Marshal
Posts: 63849
209
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Bill Platt wrote:. . . If there is a field variable with the same name as a member variable used within a method . . .

Sorry to appear pedantic, but a field is a member of the class, so variables used inside methods aren't called member variables. They are called local variables.
You are right that this.xxx disambiguates the field from the local variable.
It never does any harm to write this.xxx for every use of a field (or for that matter, use of a method), and IDEs have options to add this. to everything, but Fred is right that it is as much a matter of taste as anything else.
Don't use this.xxx for static fields or methods, however.
 
Ranch Hand
Posts: 530
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Basically, this refers to the current instance (this instance) of the enclosing class. So whenever you need to access the current instance explicitly you need to use this.
Besides using this in setter methods, I also use it to call overloaded constructors, for example:



You can learn more about this keyword in Java here
 
Ranch Hand
Posts: 99
Java Linux Monad
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The first thing you have to learn about this... This is just the object calling the method. Example:

Say we have a class:


And we create an instance of that class myThis:


Now we call ThisDemo's only method display:


And now print the value of the instance:


You'll find both display the same value because the dot notation is just syntactic sugar. The method display, contained in the ThisDemo class, is really defined like something below.


And when you call the method display, its really:
 
Campbell Ritchie
Marshal
Posts: 63849
209
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Gerard Gauthier wrote:. . . the dot notation is just syntactic sugar. The method display, contained in the ThisDemo class, is really defined like something below.
. . .

Where on earth did you get that from? There is nothing syntactic sugar‑y about the dot notation. When an instance method is called, the runtime implicitly passes a reference to the relevant object to the method, which lives in the Class<ThisDemo> object, but that is an implementation detail which doesn't even appear in the bytecode.
 
Ranch Hand
Posts: 1325
3
Java Netbeans IDE Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This is a Java resource which provides unambiguous evidence that the member is an instance instead of local or static. If it gets confusing it uses in a method it could be a signal like that the method is too complex.
 
Gerard Gauthier
Ranch Hand
Posts: 99
Java Linux Monad
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:

Gerard Gauthier wrote:. . . the dot notation is just syntactic sugar. The method display, contained in the ThisDemo class, is really defined like something below.
. . .

Where on earth did you get that from? There is nothing syntactic sugar‑y about the dot notation. When an instance method is called, the runtime implicitly passes a reference to the relevant object to the method, which lives in the Class<ThisDemo> object, but that is an implementation detail which doesn't even appear in the bytecode.



Yeah, because the environment wouldn't be sugar sitting on top of the hardware.
 
Campbell Ritchie
Marshal
Posts: 63849
209
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Please don't quote the whole of a preceding post; that simply makes your post longer without adding more information. It also doesn't make it clear which part you are saying, “Yeah,” to.
 
Sheriff
Posts: 13392
221
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Gerard Gauthier wrote:
And when you call the method display, its really:


No, no, no, no. This is NOT how Java works. It may be close to how Python works but Java is NOT Python and conversely, Python is NOT Java.
 
Gerard Gauthier
Ranch Hand
Posts: 99
Java Linux Monad
  • Likes 1 Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Junilu Lacar wrote:

Gerard Gauthier wrote:
And when you call the method display, its really:


No, no, no, no. This is NOT how Java works. It may be close to how Python works but Java is NOT Python and conversely, Python is NOT Java.



You have to understand something... They ALL work like I posted. The Java environment is just a pile of abstractions build on abstractions. When you strip it all away, the 'this' is just a pointer to the calling object and the dot notation is just an abstraction for a function call and a functional call is just an abstraction...
 
Junilu Lacar
Sheriff
Posts: 13392
221
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Gerard Gauthier wrote:
You have to understand something... They ALL work like I posted.


No, your "really works like this" code actually doesn't work. You misunderstand why those two things you say work the same produce the same result. It's definitely NOT how you characterized it. Don't be  misled by the subject: this is what the JLS refers to as a "primary expression" and it is not an implicit parameter as the subject suggests (Edit: see subsequent reply below regarding "receiver parameter"). Again, this isn't Python.

See https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.8.3
 
Saloon Keeper
Posts: 9997
208
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There is a bit of truth in both of your points of view.

Java DOES allow you to declare this as a receiver parameter in non-static methods:

It however is NOT a formal parameter, and you can't declare it anywhere else in the parameter list other than at the very beginning.

myThis.displayThis() is NOT syntactic sugar for displayThis(myThis), because the latter is not legal Java, even if you declared it as a receiver parameter. myThis.displayThis() is not even syntactic sugar for calling a static method that takes a ThisDemo instance, because static methods are not virtual:

 
Gerard Gauthier
Ranch Hand
Posts: 99
Java Linux Monad
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You understand that the dot notation is syntactic sugar right? There is nothing at the machine level that understands someObject.someMethod(), just like there is nothing at the machine level that understands someFunction(someObject). These are constructs invented in programming languages and both void someFunction(Object * this) {...} and public void someMethod() {...} do the same thing.. Pass a pointer to an object to a function/method.
 
Junilu Lacar
Sheriff
Posts: 13392
221
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Gerard Gauthier wrote:You understand that the dot notation is syntactic sugar right?


You keep using that phrase; I don't think it means what you think it means. https://en.m.wikipedia.org/wiki/Syntactic_sugar

The dot notation is a fundamental part of Java syntax and there is nothing you can use in place of it that would make Java programs work the same way, therefore, it is not "syntactic sugar" as you insist on saying.
 
Campbell Ritchie
Marshal
Posts: 63849
209
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Gerard Gauthier wrote:You understand that the dot notation is syntactic sugar right?

That leads me to wonder whether you know what “syntactic sugar” means.

There is nothing at the machine level . . . .

You are not writing assembly language, but a high‑level language. A high‑level language doesn't care what happens at the level of machine code; indeed the machine code created when I write Java® code is different from what used to happen when I wrote the same code; I am now using a 64‑bit machine and I used to write code for a 32‑bit machine. But the Java® I write can be exactly the same.
 
Gerard Gauthier
Ranch Hand
Posts: 99
Java Linux Monad
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Junilu Lacar wrote:

Gerard Gauthier wrote:You understand that the dot notation is syntactic sugar right?


You keep using that phrase; I don't think it means what you think it means. https://en.m.wikipedia.org/wiki/Syntactic_sugar

The dot notation is a fundamental part of Java syntax and there is nothing you can use in place of it that would make Java programs work the same way, therefore, it is not "syntactic sugar" as you insist on saying.



But my point still stands. The dot notation is just a function call that passes a pointer to the object behind the scenes.

SomeObject.SomeMethod();

and

SomeFunction(SomeObject);

Fundamentally do the same thing. One exposes where the 'this' comes from and the other hides it under a layer of abstraction.

This is one thing I hate about programmers and programming languages and programming paradigms. They try to make their paradigm/language/discipline out to be more than it is.
 
Bartender
Posts: 20580
121
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I didn't notice, maybe someone already said it, but "this" isn't an implicit parameter. It's an implicit member variable. Or, if you prefer, it's defined as a private member of the ultimate base class, java.lang.Object, albeit one that is not formally documented. And constructed referencing the class instance it's defined in.

This "syntactic sugar" argument is nonsense. Java isn't merely a high-level language, it's an extremely high level language and totally abstract as regards machine implementation - it's defined in terms of the JVM specs, not merely instruction sequences and it doesn't acknowledge or require such low-level things as pointers.

"this" in Java is not the same thing as "this" in C++, if that's what the inspiration for the conceit was supposed to be.
 
Junilu Lacar
Sheriff
Posts: 13392
221
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tim Holloway wrote:I didn't notice, maybe someone already said it, but "this" isn't an implicit parameter. It's an implicit member variable.


Yeah, I said it earlier but you know, I was pretty much convinced of the same thing until I debugged and stepped through the code that Stephan posted.

Apparently, something like this (see what I did there )

compiles and is equivalent to this:

I didn't think it would compile at all since this is a keyword but there again my brain failed me in that it's reserved words that cannot be used as identifiers.

This:

had this output:

com.javaranch.beginner.ThisDemo@6bdf28bb
'this' is implicit?! com.javaranch.beginner.ThisDemo@6bdf28bb
42
 
Stephan van Hulst
Saloon Keeper
Posts: 9997
208
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Gerard Gauthier wrote:But my point still stands. The dot notation is just a function call that passes a pointer to the object behind the scenes.

SomeObject.SomeMethod();

and

SomeFunction(SomeObject);

Fundamentally do the same thing. One exposes where the 'this' comes from and the other hides it under a layer of abstraction.


False. The first uses dynamic dispatch to determine what virtual method is invoked on the argument. The second uses static dispatch to invoke a possibly non-virtual method on the argument. The difference is enormous. A virtual method may be overridden and the exact version of the method that is called can only be determined at runtime.

This is one thing I hate about programmers and programming languages and programming paradigms. They try to make their paradigm/language/discipline out to be more than it is.


Well, it IS more than what you propose it is. Sometimes the whole is more than the sum of parts. In the same vein, I can answer every question on this forum with that all of this just amounts to propagating waves of electrons through metal and semi-conductors, but that wouldn't really be a helpful.

You used the term "syntactic sugar" though, and like others have already pointed out, that's different from what you mean. Syntactic sugar means that a language feature can be written differently in the same language. The access operator can NOT, because it does something completely different than passing the left operand as an argument to a method call.
 
Junilu Lacar
Sheriff
Posts: 13392
221
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Scouring the JLS right now for mentions of "implicit parameter". Found these so far:

https://docs.oracle.com/javase/specs/jls/se8/html/jls-8.html#jls-8.8.1
https://docs.oracle.com/javase/specs/jls/se8/html/jls-8.html#jls-8.8.9

Those are in the context of "a non-private inner member class, where the default constructor implicitly declares one formal parameter representing the immediately enclosing instance of the class (§8.8.1, §15.9.2, §15.9.3)"

Will update this post if I find other references to "implicit parameter" for this in the context of methods. In the meantime, if anyone else has links to other authoritative references, I'm sure everyone would appreciate you sharing those.

Edit: found "receiver parameter" per Stephan's reply below.

https://docs.oracle.com/javase/specs/jls/se8/html/jls-8.html#jls-8.4.1

Thanks, Stephan!  
 
Stephan van Hulst
Saloon Keeper
Posts: 9997
208
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The official term for it is "receiver parameter". You would only use it if you want to annotate it.
 
Tim Holloway
Bartender
Posts: 20580
121
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Anyone who thinks that binary Harvard Architecture Turing Machines are the only way to do computing doesn't understand the difference between Computing Theory and Implementations.

A while back, there was this thing called a LISP Machine. The concept was that its machine language was LISP, and LISP, for example, doesn't consider pointers as a concept. Granted, it was almost assuredly implementing a more traditional microcode, but nevertheless, the LISP paradigm was not dependent on any particular microcode, only on it's ability to implement the LISP spec, just like a JVM, although simpler. When Linus Torvalds first immigrated to the USA, he worked at a company that was basically in the business of creating custom conceptual processors. It is alas, now defunct, I believe.

You can build computing devices out of multi-state devices such as Strowger switches. You can build them out of multi-state optical switches or fluidics components. You can build them using quantum principles. Neural networks have no need for pointers, or for that matter, many other traditional Turing-based operations, and there was a division of Sprague electronics producing neural network chips back in the late 1980s. I've got a book on computing systems based on content-addressable memory, which is accessed by the values in the memory cells, not memory cell location. You can build them out of jello. IBM had quite a successful mainframe series back in the 1950s based on decimal, not binary addressing and arithmetic and BCD instructions are standard in microprocessors from at least the 8080/MC6800 up.

So, in short, do not assume that Java object references are pointers. There are more things in Heaven and Earth...

As for "sugar", the idea behind sugar is that it makes something else more palatable. If there is no "else" then you aren't "sugaring" something, because all it is is sugar. When you lose core functionality by removing something, it's patently not "flavoring" and thus not "syntactic sugar".
 
Junilu Lacar
Sheriff
Posts: 13392
221
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A cow to OP as well for posing an arguably innocent question that stirred up quite the hornet's nest of debate around this and sugar.  
 
Junilu Lacar
Sheriff
Posts: 13392
221
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

The Java Language Specification wrote:The receiver parameter is not a formal parameter; more precisely, it is not a declaration of any kind of variable (§4.12.3), it is never bound to any value passed as an argument in a method invocation expression or qualified class instance creation expression, and it has no effect whatsoever at run time.


So, this is NOT an implicit parameter then.

Am I grokking this?
 
Stephan van Hulst
Saloon Keeper
Posts: 9997
208
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm not sure if there is a philosophical difference, or if it's just because JLS says so.

Would Java be any different if we said that this is a method parameter implicitly declared on every instance method, and that we're not allowed to use it as an identifier in our own declarations?
 
Junilu Lacar
Sheriff
Posts: 13392
221
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I guess I'm more interested in being technically correct.
 
Tim Holloway
Bartender
Posts: 20580
121
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:The official term for it is "receiver parameter". You would only use it if you want to annotate it.



Ah! I was wondering if the ability to use "this" as a parameter name was some sort of evolutionary dead end I'd never heard of, but that makes sense. Otherwise the difference between "this" as an omnipresent implicit parameter and as an omnipresent implicit class member would be mostly indistinguishable.

Am I missing something in the spec? They're not using classical BNF and I'm not seeing any meta-notation to indicate optional items.
 
Junilu Lacar
Sheriff
Posts: 13392
221
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tim Holloway wrote:Am I missing something in the spec? They're not using classical BNF and I'm not seeing any meta-notation to indicate optional items.


Treat each line as an "OR"

FormalParameterList:  // this can be...
   ReceiverParameter    // this
   FormalParameters , LastFormalParameter // or this
   LastFormalParameter  // or this

FormalParameters:  // this can be...
   FormalParameter {, FormalParameter} // this
   ReceiverParameter {, FormalParameter} // or this

ReceiverParameter: // this is...
   {Annotation} UnannType [Identifier .] this

Brackets ([ ... ]) indicate optional parts.  Although I can't figure out how that [Identifier .] optional part of a ReceiverParameter works.  A working example would be great. (hint, hint, Stephan...)

Edit: Here's where they explain the notation: https://docs.oracle.com/javase/specs/jls/se8/html/jls-2.html#jls-2.4
 
Junilu Lacar
Sheriff
Posts: 13392
221
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just to beat this dead horse one more time...

Gerard Gauthier wrote:But my point still stands. The dot notation is just a function call that passes a pointer to the object behind the scenes.


I think this passage from the JLS makes it clear that there is no value being implicitly passed in as an argument.

The receiver parameter is not a formal parameter; more precisely, it is not a declaration of any kind of variable (§4.12.3), it is never bound to any value passed as an argument in a method invocation expression or qualified class instance creation expression, and it has no effect whatsoever at run time.

 
Stephan van Hulst
Saloon Keeper
Posts: 9997
208
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Junilu Lacar wrote:Although I can't figure out how that [Identifier .] optional part of a ReceiverParameter works.  A working example would be great. (hint, hint, Stephan...)


Alright alright.

You would use the identifier if you're annotating the receiver parameter of a constructor of an inner class:

It is a little bit redundant because you have to use the name of the outer type twice, but otherwise the this keyword would refer to Inner.this, and that's not valid for a receiver parameter of a constructor of an inner class. The following does NOT compile:

They probably could have inferred that this refers to the outer type so you don't have to write the type name twice, but that's quite some extra logic for a language feature that nobody uses anyway.

Now here is where it becomes really confusing: Even though the receiver parameter in a constructor refers to the instance of the outer type that you called the new keyword on, the this keyword in the body of the constructor still refers to the instance of the newly created inner class.
 
Junilu Lacar
Sheriff
Posts: 13392
221
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Excellent! Thanks again, Stephan, for all the valuable insights you've shared in this thread. Very informative. I can go bowling now
 
Ranch Hand
Posts: 67
Debian Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Suppose you have a Constructor like the following. Your formal arguments and instance variables are the same.

If you do something like this:




But the following is not. And this means the current object.

 
Bill Platt
Ranch Hand
Posts: 33
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Wow! I wasn't trying to stir something up, I was just looking for clarification.

Thanks to all who have responded. I suspect with many aspects of learning programming, it'll take a while to sink in. It also seems as though there are differences of opinions.


Tim Holloway wrote:I didn't notice, maybe someone already said it, but "this" isn't an implicit parameter. It's an implicit member variable. Or, if you prefer, it's defined as a private member of the ultimate base class, java.lang.Object, albeit one that is not formally documented. And constructed referencing the class instance it's defined in.



My choice of using "implicit parameter is based on what my textbook was calling it (see screenshot below). I am willing to admit that the textbook may not be 100% correct in the terminology that it uses, but I tend to go with what I have been given and expand from there.

thanks again everyone

Bill
screenshot.jpg
[Thumbnail for screenshot.jpg]
 
Tim Holloway
Bartender
Posts: 20580
121
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Bill Platt wrote:
My choice of using "implicit parameter is based on what my textbook was calling it (see screenshot below). I am willing to admit that the textbook may not be 100% correct in the terminology that it uses, but I tend to go with what I have been given and expand from there.



Actually, I changed my opinion when later posts showed why it acts more like a parameter than a member. My ego is sufficiently strong enough to allow correction.
 
Junilu Lacar
Sheriff
Posts: 13392
221
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This from your book:

The compiler converts that syntax into a method call with the object's reference implicitly passed as a parameter. So you can think of objectReference.method(...) getting converted to method(objectReference, ...). The object is known as an implicit parameter of the member method.



seems to be in direct contradiction with this, from the JLS:

The receiver parameter is not a formal parameter; more precisely, it is not a declaration of any kind of variable (§4.12.3), it is never bound to any value passed as an argument in a method invocation expression or qualified class instance creation expression, and it has no effect whatsoever at run time.



However, calls to instance methods are made with the invokevirtual instruction. This is the relevant section in the JVM Specification for the invokevirtual instruction: https://docs.oracle.com/javase/specs/jvms/se12/html/jvms-6.html#jvms-6.5.invokevirtual

If you (try to) read that, you'll see it includes objectref as part of the operand stack. It says "the nargs argument values and objectref are popped from the operand stack" which, to me, supports the assertion that the reference to the current object, as represented by this, is in fact put on the stack. So while the JLS says the receiver parameter is not a formal parameter and nothing is ever bound to it, deeper under the covers it still gets implemented the same way parameters are implemented: as elements pushed onto and popped from the operand stack as part of a method invocation.

This is just my long-winded way of saying, "Yeah, you can think of this as an implicit parameter."

Remember though: this all happens deep under the covers and the bulk of the discussion in this thread was really around what was technically the correct way to describe what happens. As Stephan alluded to somewhere during this discussion, there's really no philosophical difference if you think of this as an implicit parameter or implicit member.
 
I'm still in control here. LOOK at this tiny ad!
global solutions you can do at home or in your backyard
https://www.kickstarter.com/projects/paulwheaton/better-world-boo
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!