Solidity hints. Часть 23

Наш первый стрим по теме подготовки протокола к аудиту я планирую провести примерно в следующий четверг в 19:00. Встреча будет либо тут в Телеграмме, либо в Зуме. Еще проверю, где будет удобнее демонстрировать экран для презентаций. Запись не знаю будет или нет, так как не сильно пока уверен в своих способностях спикера.

Ну, а пока что, еще несколько пунктов из репо для общего понимания Solidity. Они, в целом, и так самодостаточно понятны, но мы идем по порядку, поэтому говорим о каждом. Итак:

36. When a contract inherits from other contracts, only a single contract is created on the blockchain, and the code from all the base contracts is compiled into the created contract. This means that all internal calls to functions of base contracts also just use internal function calls (super.f(..) will use JUMP and not a message call

что в переводе:

Когда контракт наследуется от других контрактов, на блокчейне создается только один контракт, а код всех базовых контрактов компилируется в созданный контракт. Это означает, что все внутренние вызовы функций базовых контрактов также используют только внутренние вызовы функций (super.f(...) будет использовать JUMP, а не вызов сообщения

Тут и так все понятно, но дам несколько комментариев.

Solidity поддерживает множественное наследование, включая полиморфизм.

Полиморфизм означает, что вызов функции (внутренней и внешней) всегда выполняет одноименную функцию (и типы параметров) в наиболее ближайшем контракте в иерархии наследования. Это должно быть явно разрешено для каждой функции в иерархии с помощью ключевых слов virtual и override.

Можно вызывать функции дальше по иерархии наследования, явно указывая контракт с помощью ContractName.functionName() или с помощью super.functionName(), если вы хотите вызвать функцию на один уровень выше в сглаженной иерархии наследования.

Грубо говоря, при наличии internal функций в наследуемых нашим контрактов всех остальных, вызовы между ними будут идти с помощью опкода JUMP, и не будут считаться вызовами в другой контракт, где используются такие опкоды как CALL или, скажем, STATICCALL.

Идем далее:

37. The overriding function may only change the visibility of the overridden function from external to public .The mutability may be changed to a more strict one following the order: nonpayablecan be overridden by viewand pure. viewcan be overridden by pure. payableis an exception and cannot be changed to any other mutability

и перевод:

Переопределяющая функция может только изменить видимость переопределяемой функции с external на public. Мутабельность может быть изменена на более строгую в следующем порядке: nonpayable может быть переопределена view и pure. view может быть переопределена pure. payable является исключением и не может быть изменена на любую другую мутабельность

Тут также все просто. Если мы наследуем от контракта, где есть virtual / override функции, которые мы хотим переписать в своем контракте, то сделать это можем только в более "строгую" сторону.

Таким образом мы не сможем переписать функцию, помеченную как view в public или external.

На самом деле, такое крайне редко когда требуется, да и компилятор будет подсвечивать вам проблемное место.

#override #inherit