side cut of static methods

[Jayesh Pawar]

class A {
	
	 static void printName() {
		System.out.println(" Base class "); 
	 }	 
}

class B extends A {	

	public static void main(String[] args) {
		new B().printName();
	}	
}

Output : Base Class


-> In Java, static method belongs to the class and not to any particular instance of the class. Also, static methods are never inherited. If yes, then how come new B().printName() calls the Base class method printName() ?

[Winston Gutkowski]

Jayesh Pawar wrote:-> In Java, static method belongs to the class and not to any particular instance of the class. Also, static methods are never inherited. If yes, then how come new B().printName() class the Base class method printName() ?

Because B is an A, and you are allowed to called static methods via an instance (something, I should add, that many of us find horrible; although I suspect the founding fathers had their reasons).

If B had declared a static method with the same signature, you would have executed it instead, but it is NOT overriding...

Winston

[Campbell Ritchie]

Welcome to the Ranch
I think there were many things which should have been omitted from the language, including calling static methods on an instance. Try B.printName(); That should work, too, unless you hide the method with another static method with the same signature.
Please find out about the code button. I have applied it to your post, and you can see how much better it looks

[Henry Wong]

Winston Gutkowski wrote:

Jayesh Pawar wrote:-> In Java, static method belongs to the class and not to any particular instance of the class. Also, static methods are never inherited. If yes, then how come new B().printName() class the Base class method printName() ?

Because B is an A, and you are allowed to called static methods via an instance (something, I should add, that many of us find horrible; although I suspect the founding fathers had their reasons).

I suspect it was done because (A) it was easy to do, and (B) it is convenient. Allowing an reference variable to be used to call a static method is easy to do for the compiler, and it is convenient (arguably) for the developer. Allowing the compiler to search up the hierarchy to find a matching static method is easy to do for the compiler, and is convenient for the developer.... but as already mentioned, just because it may look somewhat like inheritance, it doesn't mean that it is.

Henry

[Mike Simmons]

Well, it is inheritance as the JLS defines the term. I don't know what "static methods are never inherited" is even supposed to mean. Must use some other definition of inheritance. Perhaps it was supposed to refer to the fact that static methods don't use dynamic lookup, i.e. they can't be overridden? But that has nothing to do with the code example.

[Mike Simmons]

As for the issue of why static methods are accessible using instances: I don't like it either. I think it may have been allowed because it make it easier for programmers to refactor instance methods into static methods, or vice versa.

[Winston Gutkowski]

Mike Simmons wrote:Well, it is inheritance as the JLS defines the term. I don't know what "static methods are never inherited" is even supposed to mean. Must use some other definition of inheritance.

Hmmm. Really? So I should be able to run super.method() then...

Winston

[Mike Simmons]

Where does that idea come from?

[Winston Gutkowski]

Mike Simmons wrote:Where does that idea come from?

Erm...here?

And I know, you're going to tell me to look at the JLS definition; but the fact is that many students of OO (including me) regard "inheritance" as meaning inheritance via type or class hierarchy.

To me, static methods or behaviour are not "inherited" in any sense that I understand the word, since there is no hierarchy involved. They may be "seen" or "acquired" by subclasses; but that was a language decision - as was the business of allowing static methods to be referenced via instances.

Winston

[Jeff Verdegan]

Jayesh Pawar wrote:
Also, static methods are never inherited.

False. They're inherited, but there not overridden. And if both superclass and subclass define the method, unlike with overriding/polymorphism on non-static methods, the compiler determines which one to invoke based on the reference type (if we're sloppy enough to use a reference to invoke a static method), rather than the runtime determining which version based on the class of the object.

class Sub extends Super { ... }
...
Super superRef = new Super();
Super subRef = new Sub();

Super.someStaticMethod(); // calls Super's version -- determined at compile time
Sub.someStaticMethod(); // calls Sub's version -- determined at compile time

superRef.someStaticMethod(); // calls Super's version -- determined at compile time
subRef.someStaticMethod(); // calls Super's version, regardless of whether Sub also defines this method ("hides" it) -- determined at compile time

Super.someNonStaticMethod(); // compile-time error
Sub.someNonStaticMethod(); // compile-time error

superRef.someNonStaticMethod(); // calls Super's version -- determined at runtime
subRef.someNonStaticMethod(); // calls Sub's version, if Sub overrides -- determined at runtime

[Mike Simmons]

Winston Gutkowski wrote:To me, static methods or behaviour are not "inherited" in any sense that I understand the word, since there is no hierarchy involved.

Ummm... how is there no type hierarchy involved? Class B extends A. There you go.

Wikipedia:Inheritance wrote:In classical inheritance where objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes, superclasses, parent classes or ancestor classes. The resulting classes are known as derived classes, subclasses or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

This all applies 100%, regardless of whether attributes and behavior are static or not.

Winston Gutkowski wrote:They may be "seen" or "acquired" by subclasses; but that was a language decision - as was the business of allowing static methods to be referenced via instances.

There are plenty of language-specific variations on how inheritance can work. Including variations within one language, as how static and non-static inheritance can behave differently. While still being inheritance.

I am open to getting a better understanding of definitions other than those from the JLS. But I already checked the wikipedia article, and it seems to support my point, not yours.

Further, while the JLS is not the be-all and end-all of existence, it's a useful reference point for common definitions while discussing Java. And for anyone who tries to use it to find the answer to a question, it's helpful to pay attention to its definitions in order to interpret what it's saying. When people blithely state that "static methods are not inherited", and it's not challenged or even noticed, I think it makes it harder for others to talk and learn about these things without getting further confused.

[Winston Gutkowski]

Mike Simmons wrote:

Wikipedia:Inheritance wrote:In classical inheritance where objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes, superclasses, parent classes or ancestor classes. The resulting classes are known as derived classes, subclasses or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

This all applies 100%, regardless of whether attributes and behavior are static or not.

Oh no it doesn't. Mind you, it looks like I'll have Jeff arguing against me as well. Ah well, it's Friday...

If I design a language where static methods are ONLY visible by the class that defines it, I can still call it an OO language. If I specify the same rule for instance methods, it is absolutely NOT one.

That is inheritance to me. It applies to objects, not classes (except in definition terms), unless you fancy adding it to your language; and personally, I call that 'visibility', not inheritance.

And I say again, if "static inheritance" really is inheritance: I should be able to override public static x() and call super.x() from my overridden implementation. But I can't; I can only "mask" it. A whole new set of terminology for something you regard as similar, but which sounds to me like a compiler programmer's term: It's "inherited" because the JVM can call it a certain way internally, not because it's actually the same thing.

TGIF

Winston

[Mike Simmons]

So is this all "what inheritance means to me", or is there a reference somewhere that indicates it's shared by others? I've already addressed the Wikipedia link you provided, and your response seems to rely only on personal opinions of what this stuff should mean. My personal opinion is different, and so far it seems to be backed by both the JLS and Wikipedia.

[Mike Simmons]

Winston Gutkowski wrote:If I design a language where static methods are ONLY visible by the class that defines it, I can still call it an OO language. If I specify the same rule for instance methods, it is absolutely NOT one.

I'd agree, because I'd say you have to have some form of inheritance to be OO. If you decide to allow inheritance of instance but not static, fine, you've still got some sort of inheritance; you're still OO. Of you rule both forms out, it's not OO anymore. But that doesn't mean static inheritance is not inheritance.

Winston Gutkowski wrote:And I say again, if "static inheritance" really is inheritance: I should be able to override public static x() and call super.x() from my overridden implementation. But I can't; I can only "mask" it.

OK, so for you, overriding and polymorphism are required parts of inheritance, is that right? For me they're not the same thing - that's why we have separate terms for them. They are often used together, and Java combines them in certain ways. Doesn't mean that's the only way to have inheritance.

[Nikhil Sagar]

To me, static methods or behaviour are not "inherited" in any sense

i am totally agree with Winston's this statement because as i know that all the decisions about static methods are taken by the compiler at compile time. So, i think there is no need to inherit static methods.

[Winston Gutkowski]

Mike Simmons wrote:So is this all "what inheritance means to me"

Not at all. I provided a perfectly straightforward argument in my second sentence, and even if you discount that completely, I've only seen one thing in the Wiki page that refutes anything I've said: the business of code re-use. It could be argued that allowing subclasses to 'see' a superclass's static method is a form of code re-use; but "masking" most certainly is not.

As for references, I see no reference anywhere in the Wikipedia page to "static inheritance"; nor are there any examples of it applying to static methods. Could that perhaps mean that, like me, they regard inheritance as being instance-based?

Let me turn it around: Other than the JLS, can you find any generally accepted definition of "inheritance" as it applies to static methods?

Winston

[Mike Simmons]

Nikhil Sagar wrote:

To me, static methods or behaviour are not "inherited" in any sense

i am totally agree with Winston's this statement because as i know that all the decisions about static methods are taken by the compiler at compile time. So, i think there is no need to inherit static methods.

Ah, well. If you know it, it must be true.

This appears to be another vote for inheritance == overriding and polymorphism. Again, is this supported anywhere? Do people just think this because that's the way java does it (as long as you ignore static methods)? Or is it part of some well-defined terminology somewhere?

[Mike Simmons]

Winston Gutkowski wrote:

Mike Simmons wrote:So is this all "what inheritance means to me"

Not at all. I provided a perfectly straightforward argument in my second sentence

Which second sentence is that?

"Mind you, it looks like I'll have Jeff arguing against me as well."

"And I know, you're going to tell me to look at the JLS definition; but the fact is that many students of OO (including me) regard "inheritance" as meaning inheritance via type or class hierarchy."

"Really?"

The middle one is at least an argument of some sort. Not much of one, but it's something. Did you mean something else?

[Winston Gutkowski]

Mike Simmons wrote:Which second sentence is that?

Read on my friend. I'm tired, and it's bedtime here. We'll simply have to agree to disagree on this one.

Winston

[Mike Simmons]

I kept that one really simple in hopes you'd clarify "second sentence", since its completely unclear to me. I've read all your posts, thanks, and I have a longer response coming. But "second sentence" still seems like a failure to identify what you're actually talking about.

[Mike Simmons]

Winston Gutkowski wrote:I've only seen one thing in the Wiki page that refutes anything I've said: the business of code re-use.

Well it is repeated a few times - starting with that first sentence describing what inheritance is. That's the fundamental part. Stuff about overriding is not essential to the definition - nor is it ever presented as such.

Winston Gutkowski wrote:It could be argued that allowing subclasses to 'see' a superclass's static method is a form of code re-use;

Exactly.

Winston Gutkowski wrote:but "masking" most certainly is not.

Did you mean hiding, as in what static methods do as opposed to overriding? Both hiding and overriding are ways to control the code re-use, changing behavior when necessary. I agree that they are not themselves code re-use.

Winston Gutkowski wrote:
As for references, I see no reference anywhere in the Wikipedia page to "static inheritance"; nor are there any examples of it applying to static methods. Could that perhaps mean that, like me, they regard inheritance as being instance-based?

Or could it be that they just don't care whether a method is static or not, because that's orthogonal to what they're talking about?

As I noted earlier, the wikipedia article does acknowledge that hiding is an alternative to overriding. And again, nowhere does it say overriding is a requirement for inheritance. On that contrary, overriding is listed as an application of inheritance. After a more general definition that had nothing to do with inheritance.

Winston Gutkowski wrote:Let me turn it around: Other than the JLS, can you find any generally accepted definition of "inheritance" as it applies to static methods?

You've already done that. Your wikipedia link gave a definition that did not depend on whether something is static or not.

There's also the Java Tutorial, which I think a lot more people have read than the JLS:

What You Can Do in a Subclass

A subclass inherits all of the public and protected members of its parent, no matter what package the subclass is in. If the subclass is in the same package as its parent, it also inherits the package-private members of the parent. You can use the inherited members as is, replace them, hide them, or supplement them with new members:
...
You can write a new static method in the subclass that has the same signature as the one in the superclass, thus hiding it.
...

You may think the Java Tutorial would naturally support the same definitions as the JLS. You might be surprised how often that's not true - but they're entirely in agreement here.

While we're at it, note that fields can obviously be inherited, even though they cannot be overridden. But they can be hidden. Much like static methods. Inheritable without being overridable. How does that fit into your view of what inheritance is?

Even without these, "other than the JLS" seems like a pretty big exception, considering this is predominantly a Java programming forum.

[Jeff Verdegan]

Winston Gutkowski wrote:
And I say again, if "static inheritance" really is inheritance: I should be able to override public static x() and call super.x() from my overridden implementation.

You seem to be claiming that overridability is the same as inheritance, or at least is a preqquisite for it. I've never seen a definition that suggests either case. Any definition of inheritance I can ever recall having seen (which, granted, is mainly the JLS lately, which is 100% on my side here, since we're talking about Java ) basically just says that a child class "acquires" (to use your word) some facet because it's present in the parent class.

[Mike Simmons]

Mike Simmons wrote:

Winston Gutkowski wrote:To me, static methods or behaviour are not "inherited" in any sense that I understand the word, since there is no hierarchy involved.

Ummm... how is there no type hierarchy involved? Class B extends A. There you go.

So Winston, are you dropping this one? Because it seems pretty straightforward to me.

[Winston Gutkowski]

Mike Simmons wrote:So Winston, are you dropping this one? Because it seems pretty straightforward to me.

Morning Mike. No, I haven’t dropped it. It really was time for bed.

It seems to me that you went all around the houses to find the “2nd sentence” that was actually in my previous post.

An object no more “inherits” its static fields and methods than it does any other visible static field or method it uses; it’s a syntactic convenience that saves you from having to supply the class name when you refer to them (and you can put that in if you want). I will admit that Java also provides a set of rules for visibility of static names based on class hierarchy, but even there the terminology used is different.

They don’t change the behaviour of an object, and static methods can’t be defined in an interface, so they have nothing to do with type definition or specialization.

Either we’re talking about inheritance in OO terms or we might as well be talking about Biology or taxes; and if you can write an OO language without what you refer to as “inheritance” of static methods and fields then, to me, it ain’t inheritance.

Show me any reference to or example of “inheritance” using static fields or methods outside the JLS or the tutorials and I will bow and grovel at your feet. Until then I will continue to view inheritance as instance-based, and Java’s paradigm for static methods and fields as simply a re-jigged form of visibility.

And it would seem I’m not alone.

Winston

[Winston Gutkowski]

Winston Gutkowski wrote:Show me any reference to or example of “inheritance” using static fields or methods outside the JLS or the tutorials and I will bow and grovel at your feet.

Right. Hoisted by me own petard.

I'm back to grovel - but only a bit.

I've spent the last couple of hours looking at examples of static method "inheritance" on Google, and I will say this: my notion of inheritance as applying strictly to instances and behaviour, while not unique, is by no means the only one. In fact, I'd say that the whole business of "inheritance" as it applies to static methods and fields is pretty confused; not least by the fact that different languages have different rules for it.

C#, for example, apparently doesn't support static inheritance; yet I've seen an example where it actually happens, with the compiler substituting a base class name for a derived one in the bytecode (or whatever .NET calls it). The author of that post claims, however, that it is NOT inheritance. Furthermore, according to the same thread, it isn't consistent with other languages in the .NET framework

Wierdly enough, the thing that convinced me that there may be other ways of looking at it was an example in Python, and also an OO tutorial which says that if, given two classes Base and Derived, I can refer to Base.x() in Derived without having to supply the class name, then I am looking at inheritance in action. Given that definition, I'd have to concede that you're right.

However, there are also several other pages that see static "inheritance" rather more the way I do; in fact I've seen the word "scope" used quite widely. I think it could also be argued that static methods are a form of delegation rather than inheritance, since they are part of a "has-a" relationship. They also don't conform to LSP; although, as the Wiki page says, that's not necessarily a pre-condition of inheritance.

So: you've shifted me off me pedestal a bit, but not totally.

A lot more reading required on the subject for me, methinks.

Winston

[Mike Simmons]

Morning, Winston!

Winston Gutkowski wrote:It seems to me that you went all around the houses to find the “2nd sentence” that was actually in my previous post.

Well, the second sentence in the post immediately preceding was "Mind you, it looks like I'll have Jeff arguing against me as well." As I quoted. So perhaps you could quote the sentence you're actually talking about?

Off for a run...

[Winston Gutkowski]

Mike Simmons wrote:So perhaps you could quote the sentence you're actually talking about?

Sorry. Should have said "second para".

Winston

[Nikhil Sagar]

Looks like jayesh (original poster) got a lot more than he was expecting.

[Winston Gutkowski]

Nikhil Sagar wrote:Looks like jayesh (original poster) got a lot more than he was expecting.

Yeah, it happens. Perhaps we should have split it when the discussion got esoteric. All grist for the mill though.

Winston

[Mike Simmons]

Esoteric, but not off topic.