Abstrakter Vertrag, der den Konstruktor nicht vom übergeordneten abstrakten Vertrag erbt

Ich verwende Solidity 0.7.1 und scheine beim Erben von einem abstrakten Vertrag auf Probleme zu stoßen. Insbesondere bei der offenen Zeppelin-Bibliothek erstelle ich dort jetzt kein Problem, da ihr Code korrekt zu sein scheint. Außerdem scheint mein Problem eher ein Mangel an Verständnis meinerseits oder ein potenzieller Fehler im Design der Solidität zu sein.

Das Problem

Ich verwende hauptsächlich 2 abstrakte Verträge aus der Bibliothek ERC20und ERC20Burnablevererbe ERC20Burnablevon ERC20. Jetzt ERC20Burnablewerden nur noch 2 Burn-Methoden hinzugefügt, ERC20damit es nichts mit dem Konstruktor zu tun hat. Wenn ich jedoch nur von ERC20Burnablein meinem Vertrag erbe und ihn aufrufe, als hätte er einen Konstruktor, erwarte ich, dass er in der Vorfahrenkette nach oben geht und einfach den Konstruktor von verwendet, ERC20da er von ihm erbt. Aber stattdessen löst der Compiler eine Bestellung aus. Stattdessen muss ich ERC20auch importieren, davon erben und seinen Konstruktor direkt verwenden.

Ist dies das beabsichtigte Verhalten? Dies widerspricht der Natur der Abstraktion, aber ich nehme an, dass dies aus Sicherheitsgründen getan werden kann. Irgendwelche Ideen?

Antworten (1)

Es sollte in Ordnung sein, wenn Sie von ERC20 erben, aber in diesem Fall ist dies nicht erforderlich. Sie können den ERC20-Konstruktor direkt aufrufen, da er eine Basis für ERC20Burnable ist.

contract Token is ERC20Burnable {
    constructor() ERC20("My token", "ToK") public {
    }
}

Solidity hat einige Einschränkungen, daher kann sein Verhalten möglicherweise willkürlich sein.