Комментарии 11
Итак, при обсуждении подобных вещей различают структурную и номинальную подтипизацию. Структурная подтипизация основана на иерархии классов, на отношениях наследования. Если класс
Bявляется наследником классаA— он является подтипом классаA, а значит — может быть использован везде, где ожидается классA.А номинальная подтипизация основана на анализе операций, доступных для данного класса. Если класс
Bпредлагает все атрибуты и методы, предоставляемые классомA— его можно использовать везде, где ожидается наличие классаA.
Названия показались мне контринтуитивными, и я решил поискать определения.
https://en.wikipedia.org/wiki/Nominal_type_system
https://wiki.c2.com/?StructuralSubtyping
Вроде как всё наоборот: структурная (под)типизация - это типизация "по факту", по утиному принципу, а номинальная - по декларации.
Динамическую типизацию ещё называют «утиной типизацией«.
Динамическую типизацию никогда не называли "утиной типизацией", о чем и написано по приведенной вами ссылки в вики. Это совершенно разные вещи, и несмотря на то, что и там и там есть слово "типизация", но относятся они к разным понятиям.
Утиная типизация - это типизация номинальная, но для динамических яп. То, что в питонах и джеэс называют утиной типизацией, в статических яп называют номинальной типизацией.
Это определение с сайта по тайп скрипт
Я не знаю, что и где у вас написано, но сравните два определения с Вики:
Неявная типизация, латентная типизация или утиная типизация (англ. Duck typing) в ОО-языках — определение факта реализации определённого интерфейса объектом без явного указания или наследования этого интерфейса, а просто по реализации полного набора его методов.
In computer science, a type system is nominal (also called nominative or name-based) if compatibility and equivalence of data types is determined by explicit declarations and/or the name of the types. Nominal systems are used to determine if types are equivalent, as well as if a type is a subtype of another. Nominal type systems contrast with structural systems, where comparisons are based on the structure of the types in question and do not require explicit declarations.
Nominal typing
Фактически, эти системы типизации являются практически противоположными. Для утиной (не явной) типизации требуется просто реализация определенного интерфейса независимо от связей в иерархии наследования и принадлежности к какому-либо конкретному классу, тогда как для номинальной требуется явное определение типов данных.
Например, в C два типа структур с разными именами в одной и той же translation unit никогда не считаются совместимыми, даже если они имеют идентичные объявления полей, тогда как при утиной типизации это будет два совместимы между собой интерфейса.
Да, здесь моя ошибка. Наоборот все, но смысл тот-же.
Утиная типизация - для языков с динамической типизацией.
Утиная типизация для статических яп - называется структурой.
Ну вы поняли
Утиная и структурная типизации практически синонимы, но это никак не связано ни с динамической, ни со статической типизацией.
Тем более, что динамическая типизация хоть и противопоставляется статической, но эти два варианта типизации могут присутствовать в языке одновременно.
Вот, я про тоже. Что есть динамическая и статическая типизации. А есть структурная и номинальная. Первая - про свойства полей. Вторая про ооп.
Я про термтналогию. Утиная типизация используется там, где динамический яп. В статических яп для того же используют термин структурная типизация.
По крайней мере с точки зрения одного источника
Все, я кажется понял, в чем дело. Если вы читаете руководство по TypeScript с описанием Утином типизации
Утиная типизация (Duck typing), как и в случае со структурной типизацией — это принцип, определяющий совместимость типов, основываясь не на иерархии наследования или явной реализации интерфейсов, а на их описании. Утиная типизация ничем не отличается от структурной, за исключением того, что присуща лишь языкам с динамическим связыванием (динамическая типизация).
Там написано неправильно. Утиная типизация не связана с типом языка и может быть реализована и в языках со статической типизацией. Точнее язык должен иметь возможность и статической и динамической типизации одновременно, например Julia.
И по окончании статьи появляется простой вопрос: а что именно делают протоколы под капотом? Класс Protocol предоставляет реализацию isinstance/issubclass, которые проверяют именно соответствие протокола, а не MRO?
Во‑первых — базовые классы часто плохо подготовлены для их использования сторонним кодом, их тяжело включать в свои проекты из, например, сторонних библиотек. То есть — если нужно создать класс, являющийся наследником некого базового класса, существующего во внешнем модуле, может — в общедоступной библиотеке, этот класс сначала надо самостоятельно найти.
Во‑вторых — возможна ситуация, когда нельзя менять существующий код базовых классов, содержащийся в общедоступных или в любых других внешних по отношению к проекту библиотеках. Это становится проблемой в том случае, если нужно, чтобы типы, импортированные из этих вот внешних источников, выглядели бы в проекте как подтипы других типов, возможно — в комбинации с другими типами, созданными разработчиком проекта.
И наконец — этот подход противоречит самому духу Python и идее утиной типизации.
Вот с этим можно поспорить.
Во-первых, вы мешаете - базовые классы и абстрактные. Ведь чуть ранее речь шла об абстрактных классах.
Базовые классы проблем не вызываю. Хотя-бы потому, что все классы наследуются от object и это не проблема.
Нет проблем с тем, чтобы что-то менять в суперклассах. Ведь на то они и супер классы, что не отвечают за потомков. Иначе невозможно то, что например, в Джава называют контрактами. Наследники должны сами контролировать то, как они наследуются. А не ожидать подстраивание под себя суперклассов.
Тем более, если говорить об абстрактных классах. Где нет реализации.
Ну и насколько справедливо утверждение, что утиная типизация это питонизм? Это внутренний механизм. И приведение ооп питона к более классическому ооп, по примеру джавы той же, это логическое развитие. Думаю, в будущем вообще типизация будет не информировать, а обзывать соблюдать типы.
Протоколы в Python