Documentation gap: Constructor inheritance

bgrommes

The topic of constructor inheritance is not directly addressed in the docs (that I can find anyway).

I presume that constructors are not inherited from any parent class and that one must call Super.ConstructorName() from a constructor in an inherited class if the inherited class constructor implementation is intended as an augmentation of some constructor in the parent class. This implies that the Overrides keyword is illegal for a constructor definition.

I further presume that any class that doesn't have a constructor defined has an implicit, compiler-provided empty constructor with no implementation.

These are the .NET rules off the top of my head and I haven't tested Objo thoroughly to see if you're following those conventions, but regardless, this should be accurately addressed in the docs.

Garry

Thanks, you're right that this wasn't documented, and it will be covered in the Classes page under "Constructors" and "Constructors and Inheritance" when the next release drops.

The rules differ from .NET in a couple of ways worth knowing:

A subclass that declares no constructor of its own inherits the parent class's constructors, so New Dog("Rex") works even if Dog declares nothing. Once a subclass declares any constructor, only those declared constructors are available to New.
Objo never calls the parent constructor automatically. You must call Super.Constructor(...) explicitly, and without it the parent's constructor body never runs (inherited properties keep their defaults).
A class with no constructor anywhere in its chain can be constructed with New ClassName(), with every property at its default value. If the class declares at least one constructor, that implicit construction goes away.
Constructors don't participate in overriding, so Override isn't part of a constructor declaration.

One difference from .NET: argument mismatches against a class that declares no constructor are only reported at runtime, because the checker has no constructor signatures to validate against.

bgrommes

Garry Thanks Garry ... I actually like your rules better.

In fairness to .NET, hindsight is 20/20 and there will doubtless be things 5 years from now in Objo that, in retrospect, you will wish you had decided differently, and which a greenfield competing product could in fact learn from.

That said, I have never had higher confidence in a vendor's judgment, and I've been around for a few days. I doubt that in 2031 you will regret anything to the extent that you'd introduce breaking changes around it. And for people coming here from Xojo, that's a particularly comforting thought, I'd imagine ;-)

Garry

That’s exceptionally kind of you to say, thank you 🙂

I’m certain I’ll make decisions that hindsight would change; no language designer gets everything right, and Objo won’t be an exception.

What I can promise is that compatibility and predictability will carry a lot of weight. If a breaking change ever becomes necessary, it should be rare, clearly justified, communicated well in advance, and accompanied by a practical migration path. Experiences elsewhere have made me very conscious of how much trust developers place in that stability.

Reports like this help enormously. Turning implicit behaviour into documented, tested semantics gives users and me a firmer contract to rely on.

And if I fall short, you have my permission to quote this back to me in 2031!