Still missing constructor inheritance / static method inheritance

[procodix]

This continues / reopens #2841.

Still missing is the ability to add constructors to a larger class hierarchy without having to resort to crude language constructs. PHP and Swift support this much more elegantly with static inheritance + covariance or constructor inheritance.

Simply explained using the example of an HTML DSL.

This is how it should look:

new Element(
    new Heading(1, "content"),
    new Paragraph("content",
        new Element("content")
    )
)

This is what would be needed:

Element(params [Element] elements) {}
Element(string content, params [Element] elements) {}
Element(string content, string cssClasses) {}
Element(string content, string cssClasses, params [Element] elements) {}

Every derived class needs them.

Proposed solution so far:

• Factory methods are ruled out because there is no static inheritance. static Element.create(...) -> Element would not be inherited to static Paragraph.create(...) -> Paragraph but to something completely useless and unwanted: static Paragraph.create(...) -> Element.
• Generic methods/constructors new Element<Paragraph>(...) are bulky ugly, because they require repetition and knowledge of the class hierarchy. This is especially important in a case where it would be necessary to call a constructor in the middle of the class hierarchy AdvancedElement because it performs initialization that the base Element class does not know about.

PHP / Swift do this with simple static methods with a covariant return type of "Self" or "static", which can be used as constructors or factory methods. Btw, this shows, that they are used, interpreted and handled as equal concepts.
Element(string content): self or static, and these methods are inherited with correct return types too.

C# "inherits" those static methods as well officially, but under the hood rewrites the calls to the wrong original method. Paragraph::create(...) would be compiled to Element::create(...). However if I copied the method from Element to Paragraph it would work but in a class hierarchy that would mean lots of stupid copy&paste everywhere.

So far also nobody could explain what good it is to be able to call a static Paragraph.create(...) on an inherited class, but the compiler makes Element.create(...) out of it. This is completely counterintuitive and the code does not reflect what really happens. The behavior changes completely, if - explained above - I copy the method over to Paragraph.

[HaloFour]

IMO it doesn't make a lot of sense to force all derived types within a hierarchy to accept the same state on construction as that assumes that you can define a lowest-common denominator of state that would apply to every derived type. It makes it impossible for a derived type to have additional required state as you cannot force construction to supply them. Most type hierarchies aren't like your HTML DSL example, and even in that case I don't think it makes sense to have all HTML elements within the DSL accept the same state.

If C# were to do anything here I think it'd make more sense for it to provide a similar feature to C++ where you can specify that base constructors are "copied" into the derived type. You could accomplish that today with source generators.

So far also nobody could explain what good it is to be able to call a static Paragraph.create(...) on an inherited class, but the compiler makes Element.create(...) out of it.

I'm going to assume that it was about making it easier to discover helper static methods declared on a type within a hierarchy without having to remember exactly which type declared that static method, e.g. Control.Invoke. Or maybe it was simply because you can still see the base instance members on an instance of a derived type. Or maybe it's because C++ and Java allow it. Given that was a design choice from 20+ years ago it might be difficult to find a "reason" as to why it was decided to that.

[procodix]

I'm going to assume that it was about making it easier to discover helper static methods declared on a type within a hierarchy ...

Your assumption is about the reasoning for retaining the visibility of inherited the methods. The problem is the created ambiguity. Same static method could be called on two classes. And if I simply "copy" the method from the parent to its child class, it might behave differently, as if it was copied and modified. Thats a design flaw.

[HaloFour]

The same is true for non-virtual instance members, since they can be shadowed in derived classes but the dispatch is based on the type of the instance variable. Whether you consider that to be a design flaw doesn't really matter, that's how these languages have always worked, and that cannot be changed at this point.

[procodix]

There is really no reason why it couldn't be changed. A simple suggestion is at #8243

[procodix]

It makes a lot of sense. Derived types can supply additional constructors and chain in others. Class families don't share state but behavior and therefore constructors. In PHP it works as follows:

Heading extends Element {
    // factory method
    public static function InstanceByLevelContent(int $level, string $content):static {  
        return static::InstanceByContent($content)  // call base constructor
             ->LevelSet(1) // fluent interface
        ; 
    }

    public function LevelSet(int $i):static {
        ...
        return $this;
    }
}

[HaloFour]

So you can't call Heading.InstanceByLevelContent with just the content?

[procodix]

You could, that is what Heading::InstanceByContent(). But then you would have to change the Level property manually. Since heading extends Element it makes sense to provide more specialized constructors while retaining the simpler ones.

[procodix]

No, thats what the parameters are for. This is just a very short & simple example. The whole library is very fluent to allow fast creation and configuration of HTML objects. The constructor initialization in C# is not powerful enough, so we need methods. But the important thing here is: every Element brings a InstanceByContent() method - and that totally makes sense.

[HaloFour]

Sorry, I missed that the factory method had a different name. So Header also "inherits" InstanceByContent from Element which only accepts content as a parameter. Presumably the "inherited" InstanceByContent method also needs to have a reasonable default for level otherwise you couldn't initialize the required state for that element. And if there is no reasonable default, what do you do? Throw a runtime error? And what about elements where content doesn't make sense? You can drop it on the floor, but you can't affect the API. IMO, that's where this stops making sense, the state of the class is specific to that class, and it's not reasonable for a derived class to be limited to having to handle the lowest common denominator of state as stipulated by whatever the base class happens to be. Very few OOP languages work like this.

[procodix]

About the reasonable defaults: That is the whole point of correct inheritance. If it is inherited we can assume there is a reasonable default, otherwise it should not be inherited, but composed. We leave that decision to the programmer. Since every property gets initialized to null that decision is purely logical an can be left to the api designer.

[procodix]

Sorry for the late replies. Github didnt notify me on comments. And we just got a new project with c# so I wanted to revive the proposal.

[procodix]

Closing this in favor of #8243