It is not obvious how to override a method

bgrommes

Problem

I have a class where I want to override ToString(). There's an Override keyword but it's unclear where it goes in the IDE. I tried putting Override ToString in the method name but Override just disappears when you exit the field.

Proposed Solution

A checkbox in the UI for Override

Alternatives Considered

I suppose one can just assume that a method with the same name as a method in a parent class (Object in this case) IS an override. But it seems like this should be specifically intended and expressed in the design,.

This also raises the issue of whether a method can "hide" or "shadow" another if you fail to declare it's an override. I never thought that should even be legal in .NET. I see it as cruft. I hadn't thought about this in awhile and looked it up. I think this is a pretty good summary:

"Avoid Hiding because it introduces code smells and disrupts deep inheritance chains. Use it strictly for working around "brittle base classes"—such as when a third-party library update adds a method that accidentally matches an existing method name in your derived class."

I guess that's why it was left in C# at least -- but I have never had to use it for that. As far as I'm concerned, hiding / shadowing is more likely to happen by accident if you allow a matching method without an override, than it is going to benefit you in some obscure 3rd party library situation.

Garry

Thanks, this is a good catch.

In Objo, Override is intended to be a method modifier, not part of the method name. In raw source form it should read:

Override Function ToString() As String
    Return "..."
End Function

or, with an explicit scope:

Public Override Function ToString() As String
    Return "..."
End Function

Studio’s method editor currently exposes scope, shared, async, return type, etc., but not Override, so entering Override ToString in the name field is understandably confusing. A checkbox/toggle for Override in the method metadata panel is the right fix.

On the design point: I agree that silent hiding/shadowing is not something I want. The intended model is explicit overrides. The compiler already rejects ordinary superclass method hiding without Override, but your ToString() example exposes an inconsistency around methods inherited directly from Object. I will make that consistent too, so overriding Object.ToString() is explicit and discoverable.

I’ll accept this as a Studio improvement and add an Override checkbox to method metadata, preserve it in generated declarations, and tighten/clarify the compiler/docs behaviour around Object methods such as ToString().

https://feedback.objo.dev/bug/520