Dennis Diment

Greenhorn
+ Follow
since Dec 31, 2003
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Dennis Diment

Static methods and static variables are loaded when the class is loaded. This means both go on the heap. Right?

How about local variables in static methods? Is a stack frame generated for static methods? Why else do they not get default values? (I'm not a CS major )

Dennis
19 years ago
"You cannot create instance variables in a static method, only method-local variables."
main() is a static method. In each of the above examples objects are instantiated in main(). Object references there certainly are method-local, but they are objects all the same.
"These are scoped to the method only (or more localised to blocks within the method) and will go out of scope at the latest when the current method invocation exits."
Aren't instance variables method-local in non-static methods as well? Aren't all instance variables method-local/block-local?
I am new at this. Am I misunderstanding something fundamental here?
The point of my original post is getting somewhat lost. My question is about the behavior of dynamic binding.
To reiterate: if it's true that, in the case of an instance method the actual object determines the implementation regardless of where the reference variable lies in the inheritance hierarchy, and in the case of a static method the reference variable determines the implementation, why do I get the results that I showed in my original post? (There's no sense in duplicating the code here.) equals() is a non-static instance method in both cases (in both class Object and class A). Yet, the reference variable is doing the choosing (determining the implementation).
I'm wondering if it's because the context it's all being done from is static. Actually, this solution doesn't seem right to me. I just don't know what else to think.
Thanks again.
Dennis Diment
ps - If I don't figure this out soon, I'm going to give up on programming and learn how to shoe horses.
20 years ago
[/I]"No, you cannot invoke a static method from within a non-static context"[/I]
That's not what I asked. Maybe I didn't express my problem clearly enough. My question pertains to a different scenario: when an instance method in an object created in a static context is invoked from that static context does it behave like a static method in terms of dynamic binding?
In the first example below, a1 and a2 are references of type Object. In the second example, they are of type A. Other than that, the programs are identical. They produce different results because different implementations of equals() are being invoked. This shouldn't be happening, according to the rule (more fully) stated in my original post: "when invoking an instance method . . . the class of the actual object . . . decides which implementation of the method is used . . . When accessing a field or static method, the declared type of the reference variable decides . . ." Why, then, in the first example, is the reference type of the variables deciding which implementation of this instance method to use?
I'm wondering (guessing) if it's because the object is created and used in a static context? I'm shooting in the dark here (the last resort of the confused).

Your statement (quoted above) leaves me a little confused. In the following example I'm calling a static method from two different non-static contexts, both without a class-name qualifier.

I know the class name qualifier can be used without having to create an object, but the static member can actually be used from a non-static context without it.

Thanks.
Dennis Diment
20 years ago
In one Java textbook (Liang) is the following quote: "When invoking an instance method from a reference variable the class of the actual object referenced by the variable decides which implementation of the method is used at runtime. When accessing a field or static method, the declared type of the reference variable decides which method is used at compilation time."
Is it also true that when an instance method in an object created in a static context is invoked from that static context it behaves like a static method in terms of dynamic binding?
I have a situation that appears to demonstrate that that is the case. It's a little lengthy to post.

Thanks.
Dennis
20 years ago
Well that sure clears it up. I'll have to learn my way around the language specification pages.

Let's move this to the Intermediate forum.


Being a beginner I don't really know what's elementary and what's intermediate. I guess this means I'm being fined 10 posts at the beginner forum. (BTW - I actually have an old show saddle not far from my computer. Does this get brownie points to make up for part of the fine?)
Thanks a lot for the link!
Dennis
20 years ago
My understanding is that non-static fields are given default values before the object is instantiated, whether or not they are later given non-default initialization values when it is instantiated (Mughal/Rasmussen p. 342). Does this happen when the class is loaded, along with static members, or when the *new* operator is called on a class's constructor and before the constructor is actually run? Or . . .
The problem I'm having is understanding why it is that, during initialization of an object, a field can be written to before it's declared, but can't be read before it's declared. If an int can have its default zero overwritten before the thread of execution reaches its declaration/initialization, why can't it be read? (I can't think of any reason why you'd ever want to, I just want to know how this works.)
M/R provide this example (p. 333):

At the line labeled (3), how can there be a 'this'? The object is in the middle of being constructed. If it means *'this' so far*, or *this such as it is at (3)*, then why is this.width readable and width, as in line (2), not readable?
There's something in this whole scenario I'm missing, that would probably answer all these questions.
Thanks in advance.
Dennis
ps - this is my first visit to the ranch. This is probably one of Java's best kept secrets (not that it should be).
20 years ago
My understanding is that non-static fields are given default values before the object is instantiated, whether or not they are later given non-default initialization values when it is instantiated (Mughal/Rasmussen p. 342). Does this happen when the class is loaded, along with static members, or when the *new* operator is called on a class's constructor and before the constructor is actually run? Or . . .
The problem I'm having is understanding why it is that, during initialization of an object, a field can be written to before it's declared, but can't be read before it's declared. If an int can have its default zero overwritten before the thread of execution reaches its declaration/initialization, why can't it be read? (I can't think of any reason why you'd ever want to, I just want to know how this works.)
M/R provide this example (p. 333):

At the line labeled (3), how can there be a 'this'? The object is in the middle of being constructed. If it means *'this' so far*, or *this such as it is at (3)*, then why is this.width readable and width, as in line (2), not readable?
There's something in this whole scenario I'm missing, that would probably answer all these questions.
Thanks in advance.
Dennis
ps - this is my first visit to the ranch. This is probably one of Java's best kept secrets (not that it should be).
20 years ago