Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Why uninherited methods cannot be overriden?  RSS feed

 
Ramsin Khoshaba
Ranch Hand
Posts: 65
7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The title says it all: if b.B extends a.A and does not inherit m(), then b.B cannot override m(). Why?

Maybe I'm asking this question because I've not truly understood "overriding," but either way I'm used to the phenomenon called polymorphism.
Could you define method overriding in terms of implementation, rather than examples?

Thank you...
 
Campbell Ritchie
Marshal
Posts: 55707
163
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If the method is not inherited, it will constitute a “new” method in your class.
 
Ramsin Khoshaba
Ranch Hand
Posts: 65
7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
But in C++ one may have virtual private methods, which means that they can be overridden, despite of being private.

That's one reason why I asked my first question.
 
Campbell Ritchie
Marshal
Posts: 55707
163
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You are writing Java® not C++. The languages are different. You can cause yourself dangerous confusion by thinking the two are the same.
 
Steffe Wilson
Ranch Hand
Posts: 165
12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm not sure I fully understand your question Ramsin. However in CPP a function is termed 'virtual' to cause late binding. Java implements late binding too, but it does this by default, without requiring a 'virtual' keyword. If you refer to an overridden method in java using an object reference of the base class then at run-time the derived method will be invoked rather than the base method. Is this what you meant?

 
Ramsin Khoshaba
Ranch Hand
Posts: 65
7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator



m() from b.B does not override m() from a.A because m() is not inherited from a.A. They are actually two separate methods.
Why uninherited methods cannot be overriden, in Java?

I learned recently how access modifiers work, and I'm trying to grasp overriding in a way that does not contradict my understanding.
There are different ways to comprehend inheritance in general. Different languages and authors describe inheritance differently...
 
Steffe Wilson
Ranch Hand
Posts: 165
12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
 
Ramsin Khoshaba
Ranch Hand
Posts: 65
7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Steffe Wilson wrote:


In your case, B inherits m() from A because the classes belong to the same package and m() is not private.
Inherited methods can be overridden.
 
Henry Wong
author
Sheriff
Posts: 23283
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ramsin Khoshaba wrote:
m() from b.B does not override m() from a.A because m() is not inherited from a.A. They are actually two separate methods.
Why uninherited methods cannot be overriden, in Java?


Well, the short answer to this "why" question is ... that is how it is defined in the Java Language Specification.

Unfortunately, if you want a more detailed answer than that, you probably have to contact Sun/Oracle, and hopefully, find one of the language designers, for that.

Henry
 
Mark A Carter
Greenhorn
Posts: 8
Chrome Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm still new, but it looks as if that's the point of access modifiers. Making a method default or private, is because you don't want the method to be inherited. If you want it inherited by all subclasses, no matter the package, it would be best to use the protected modifier.
 
Bhushan Bhawsar
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We override a method when we need to provide a new implementation in our subclass, but in the first example where the classes are in different packages, the subclass has no information that there is method m () present in the super class (due to access modifiers used), so it cannot override it. We cannot override something which we can not see i.e not inherited. If we write a method m() in subclass then it will be a new method in class with no override.
 
Campbell Ritchie
Marshal
Posts: 55707
163
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mark A Carter wrote:. . . Making a method default or private, is because you don't want the method to be inherited. If you want it inherited by all subclasses, no matter the package, it would be best to use the protected modifier.
Not quite. If you don't make a member private, then it is accessible in the same package where it can be inherited or overridden. If you mark a member protected, it is only accessible in the same package and in subclasses (well, more or less).

But as you suggest, you can use different access modifiers to make members accessible/inherited or otherwise in subclasses.
 
Winston Gutkowski
Bartender
Posts: 10573
65
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bhushan Bhawsar wrote:We override a method when we need to provide a new implementation in our subclass, but in the first example where the classes are in different packages, the subclass has no information that there is method m () present in the super class (due to access modifiers used), so it cannot override it. We cannot override something which we can not see i.e not inherited. If we write a method m() in subclass then it will be a new method in class with no override.

Right. And, as Henry said, that's how Java defines it.

But TBH, it also just makes sense. If everything can be overridden, then what's the point of having a private (or indeed default) qualifier for a method?

Perhaps a more pertinent question: When was the last time you overrode a private method in C++, and why did you do it? I was a C++ programmer for 3 years or so, and it never even occurred to me that such a facility might exist - indeed, the whole idea of a private virtual method seems nonsensical to me; except possibly in a nested class.

Winston
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!