There needs to be a companion to the final keyword in .

Background: The "final" keyword indicates that a method cannot be overridden in a child class.

Wish: There needs to be a first keyword to prevent accidentally creating a method ancestor which might get completely bypassed because a descendant doesn't call parent::[method] because it doesn't expect one to exist.

Either that, or a way to allow calls to parent::[method]() even when there's no method ancestor.

...or else a way to define a method such that each generation gets called automatically -- except that takes away sequencing control, which would cause problems.

· · Web · 3 · 1 · 3

@GoatSara It would cause an error if you tried to implement the same method in a parent class.

Let's say X is a method which needs to be called in every class because it initializes things. If class B descends from class A, and class A contains X(), then B::X() needs to call parent::X() so that A::X() gets called -- but if B::X() was written before A::X() existed, and the author of A::X() forgets that B::X() exists and doesn't call parent::X(), then A::X() won't get called.

Here's how it would work.

Example 1: without "first"

class A {
function X() {}
class B extends A {
function X() {}

Language processor sees no problem.

Example 2: with "first"

class A {
function X() {} // this gives an error
class B extends A {
first function X() {}

@woozle I have trouble fully understanding but it looks like something I have never seen before

@GoatSara Do you understand the need for it, or maybe that's where I need to explain more?

@woozle I cannot really understand why there would be a need

@GoatSara Do you understand the need for being sure that A::X() gets called from B::X()?

@GoatSara That covers all of my current usage cases I think, yes.

So then the problem arises when I've got B::X(), which originally had no parent to call, and then (some time later) I go and create A::X() because I realize there's some initialization which needs to be done, and I forget that B::X() exists (or that it doesn't already call parent::X())...

...and then either I wonder why A::X() isn't getting called, or maybe I guess that this is the problem but it takes me a long time to trace down through the class structure to figure out that B::X() is the culprit.

(Note that in practical use, A and B are often separated by several layers of classes and often traits as well -- the offending X() could be in any of them.)

Is that making sense yet?

@woozle Yeah it makes a bit sense to fix some class problems

@woozle yes i feel exactly what you mean

super methods sometimes need to be replaced by the override, but sometimes actually need to be wrapped instead, and if you do it wrong things can explode :D

this has been a problem for me in real life :D

@woozle Nice idea, _first_ would be an intuitive name for that!

@woozle I kept thinking about this concept, and how to extend it. Too much perhaps. ;-)
If we call it "required" we could combine it with "first"/"last" keywords to specify if parent should be run automatically before or after its children. But then again the children might want to have a say in that.
#Inheritance is tricky stuff.

@remaster I used to want automatic calling -- but the more I thought about it, that kind of "magic" behavior is best avoided where there's an alternative, and first/final provides a pretty good alternative. It's both simple and flexible.

It would also be nice if there was a way of calling a parent-method that might not exist, without causing an error (or having to explicitly check for it using method_exists()... I'm not even sure what gyrations might be necessary to make that work!), to pre-emptively acknowledge the fact that if a parent-method comes to exist at some point, it will need its child to call it.

[Insert joke here about how children never call their parents, and when they do all they give you are arguments.]

@woozle Yeah, calling the parent automatically might be too much magic.

Love the hypothetical joke at the end. ^_^

Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!