3 added 93 characters in body
source | link

I would consider this not just bad practise but thwarting the principles of OOP because a super call is a different form of call: it is a direct call that bypasses the virtual dispatch mechanism (this is how infinite recursion is avoided when you are trying to call up the class hierarchy from an override).

When you switch methods, e.g. from someMethod to someOtherMethod, typically in OOP, you want a new full virtual dispatch for the someOtherMethod invocation, which is to say that you want the first handler to be the true class of the object, not some base class.

Consider that the true class of the object (for this) is really some subclass, XYZ, that the current lines of code in your example don't know about (and shouldn't have to). That subclass may have chosen to override someOtherMethod, and when it is invoked (from an client outside the class hierarchy, and even from within the implementation of some other method within the class hierarchy), that's where the call should go.

If we didn't have full virtual dispatch for virtual methods invoked from within base class method implementations, much of the power of the OOP virtual method and override mechanism would be lost.

In short (unless you really know what you're doing and you're trying to do something unusual), you should only use a super call to call up the class hierarchy on the same method and from within an override of that method. (Some languages won't even let you invoke super on another method or outside an override.)

I would consider this not just bad practise but thwarting the principles of OOP because a super call is a different form of call: it is a direct call that bypasses the virtual dispatch mechanism (this is how infinite recursion is avoided when you are trying to call up the class hierarchy from an override).

When you switch methods, e.g. from someMethod to someOtherMethod, typically in OOP, you want a new full virtual dispatch for the someOtherMethod invocation, which is to say that you want the first handler to be the true class of the object, not some base class.

Consider that the true class of the object (for this) is really some subclass, XYZ, that the current lines of code in your example don't know about (and shouldn't have to). That subclass may have chosen to override someOtherMethod, and when it is invoked (from an client outside the class hierarchy, and even from within the implementation of some other method within the class hierarchy), that's where the call should go.

If we didn't have full virtual dispatch for virtual methods invoked from within base class method implementations, much of the power of the OOP virtual method and override mechanism would be lost.

In short (unless you really know what you're doing and you're trying to do something unusual), you should only use a super call to call up the class hierarchy on the same method and from within an override of that method.

I would consider this not just bad practise but thwarting the principles of OOP because a super call is a different form of call: it is a direct call that bypasses the virtual dispatch mechanism (this is how infinite recursion is avoided when you are trying to call up the class hierarchy from an override).

When you switch methods, e.g. from someMethod to someOtherMethod, typically in OOP, you want a new full virtual dispatch for the someOtherMethod invocation, which is to say that you want the first handler to be the true class of the object, not some base class.

Consider that the true class of the object (for this) is really some subclass, XYZ, that the current lines of code in your example don't know about (and shouldn't have to). That subclass may have chosen to override someOtherMethod, and when it is invoked (from an client outside the class hierarchy, and even from within the implementation of some other method within the class hierarchy), that's where the call should go.

If we didn't have full virtual dispatch for virtual methods invoked from within base class method implementations, much of the power of the OOP virtual method and override mechanism would be lost.

In short (unless you really know what you're doing and you're trying to do something unusual), you should only use a super call to call up the class hierarchy on the same method and from within an override of that method. (Some languages won't even let you invoke super on another method or outside an override.)

2 added 287 characters in body
source | link

I would consider this not just bad practise but thwarting the principles of OOP because a super call is a different form of call: it is a direct call that bypasses the virtual dispatch mechanism (this is how infinite recursion is avoided when you are trying to call up the class hierarchy from an override).

When you switch methods, e.g. from someMethod to someOtherMethod, typically in OOP, you want a new full virtual dispatch for the someOtherMethod invocation, which is to say that you want the first handler to be the true class of the object, not some base class.  

Consider that the true class of the object (for this) is really some subclass, XYZ, that the current lines of code in your example don't know about (and shouldn't have to). That subclass may have chosen to override someOtherMethod, and when it is invoked (from an client outside the class hierarchy, and even from within the implementation of some other method within the class hierarchy), that's where the call should go.

If we didn't have full virtual dispatch for virtual methods invoked from within base class method implementations, much of the power of the OOP virtual method and override mechanism would be lost.

In short (unless you really know what you're doing and you're trying to do something unusual), you should only use a super call to call up the class hierarchy on the same method and from within an override of that method.

I would consider this not just bad practise but thwarting the principles of OOP because a super call is a different form of call: it is a direct call that bypasses the virtual dispatch mechanism (this is how infinite recursion is avoided when you are trying to call up the class hierarchy from an override).

When you switch methods, e.g. from someMethod to someOtherMethod, typically in OOP, you want a new full virtual dispatch for the someOtherMethod invocation, which is to say that you want the first handler to be the true class of the object, not some base class.  

If we didn't have full virtual dispatch for virtual methods invoked from within base class method implementations, much of the power of the OOP virtual method and override mechanism would be lost.

I would consider this not just bad practise but thwarting the principles of OOP because a super call is a different form of call: it is a direct call that bypasses the virtual dispatch mechanism (this is how infinite recursion is avoided when you are trying to call up the class hierarchy from an override).

When you switch methods, e.g. from someMethod to someOtherMethod, typically in OOP, you want a new full virtual dispatch for the someOtherMethod invocation, which is to say that you want the first handler to be the true class of the object, not some base class.

Consider that the true class of the object (for this) is really some subclass, XYZ, that the current lines of code in your example don't know about (and shouldn't have to). That subclass may have chosen to override someOtherMethod, and when it is invoked (from an client outside the class hierarchy, and even from within the implementation of some other method within the class hierarchy), that's where the call should go.

If we didn't have full virtual dispatch for virtual methods invoked from within base class method implementations, much of the power of the OOP virtual method and override mechanism would be lost.

In short (unless you really know what you're doing and you're trying to do something unusual), you should only use a super call to call up the class hierarchy on the same method and from within an override of that method.

1
source | link

I would consider this not just bad practise but thwarting the principles of OOP because a super call is a different form of call: it is a direct call that bypasses the virtual dispatch mechanism (this is how infinite recursion is avoided when you are trying to call up the class hierarchy from an override).

When you switch methods, e.g. from someMethod to someOtherMethod, typically in OOP, you want a new full virtual dispatch for the someOtherMethod invocation, which is to say that you want the first handler to be the true class of the object, not some base class.

If we didn't have full virtual dispatch for virtual methods invoked from within base class method implementations, much of the power of the OOP virtual method and override mechanism would be lost.