Құрылымдық типтеу жүйесі: типтердің үйлесімділігі құрылымымен анықталады, атымен емес. Басқа типтеу жүйелерінен өзгешеліктері, мысалдары мен ерекшеліктері.
Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.
Кіріспе
Тип жүйелерінің класы
Class of type systems
Құрылымдық типтік жүйе (немесе қасиетке негізделген типтік жүйе) – типтік жүйелердің маңызды класы болып табылады, онда типтердің үйлесімділігі мен эквиваленттілігі типтің нақты құрылымы немесе анықтамасымен, атауы немесе жариялану орны сияқты басқа ерекшеліктерімен емес, анықталады. Құрылымдық жүйелер типтердің тең балама екенін және бір типтің екіншісінің ішкі түрі болып табылатынын анықтау үшін қолданылады. Бұл номинативтік жүйелерден, онда салыстырулар типтердің атауларына немесе нақты жарияламаларға негізделген, және динамикалық типтеуден (duck typing), онда үйлесімділік тек орындалу кезінде қол жеткізілетін құрылымның бір бөлігі арқылы тексеріледі, өзгеше.
A structural type system (or property based type system) is a major class of type systems in which type compatibility and equivalence are determined by the type's actual structure or definition and not by other characteristics such as its name or place of declaration. Structural systems are used to determine if types are equivalent and whether a type is a subtype of another. It contrasts with nominative systems, where comparisons are based on the names of the types or explicit declarations, and duck typing, in which only the part of the structure accessed at runtime is checked for compatibility.
Сипаттама
Құрылымдық типте, егер екінші элементтің түріндегі әрбір мүмкіндік үшін бірінші элементтің түрінде сәйкес және бірдей мүмкіндік болса, элемент екіншісімен үйлесімді деп есептеледі. Кейбір тілдерде мүмкіндіктердің атаулары сәйкес келуі керек пе, жоқ па, деген сияқты егжей-тегжейлі мәліметтер бойынша айырмашылықтар болуы мүмкін. Бұл анықтама симметриялық емес және субтип үйлесімділігін қамтиды. Егер екі тип бір-бірімен үйлесімді болса, олар бірдей деп саналады. Мысалы, OCaml нысан түрлерінің үйлесімділігі үшін әдістерде құрылымдық типтеуді қолданады. Go әдістерде құрылымдық типтеуді түрдің интерфейспен үйлесімділігін анықтау үшін қолданады. C++ үлгі функциялары тип аргументтерінде құрылымдық типтеуді көрсетеді. Haxe құрылымдық типтеуді қолданады, бірақ сыныптар құрылымдық түрде субтиптелмейді. Субтип полиморфизмін қолдайтын тілдерде субтип қатынасының қалай анықталғанына байланысты ұқсас екіұштылық пайда болуы мүмкін. Бір тип басқасының субтипі болып табылады, егер және тек қана егер ол базалық типтің немесе оның субтипіне тән барлық мүмкіндіктерін қамтитын болса. Субтипте қосымша мүмкіндіктер, мысалы, негізгі типте жоқ мүшелер немесе күшті инварианттар болуы мүмкін. Haskell сияқты кейбір тілдер күтілетін тип жарияланған жағдайда (яғни, қорытындыланбаған жағдайда) құрылымдық түрде алмастырмайды, мысалы, тек типтік қорытындылау арқылы полиморфты қолтаңбалы функцияларды алмастырады. Онда кездейсоқ түрді субтиптеу мүмкін емес, бірақ бұл әлі де жасырын түрде шақырылған, анықталмаған түрге түрлендіруді ұсынуға болады. Құрылымдық субтипілеу номинативтік субтипілеуге қарағанда икемдірек, өйткені ол ad hoc типтері мен протоколдарды жасауға мүмкіндік береді; атап айтқанда, ол қолданыстағы типтің анықтамасын өзгертпей, оның супертипі болып табылатын типті жасауға мүмкіндік береді. Алайда, бағдарламашы жабық абстракцияларды жасағысы келген жағдайда бұл қажет болмауы мүмкін. Құрылымдық типтеудің номинативтік типтеумен салыстырылатын кемшілігі - әр түрлі мақсаттар үшін арналған, бірақ кездейсоқ бірдей қасиеттерге ие екі бөлек анықталған типті (мысалы, екеуі де бүтін сандар жұбынан тұрады) типтік жүйемен бірдей тип деп санауға болады, өйткені олардың құрылымы бірдей. Мұны болдырмаудың бір жолы - әр пайдалану үшін бір алгебралық дерек типін жасау. 1990 жылы Кук және авторлар мұрагерлік құрылымдық типтелген объектіге бағытталған тілдерде субтипізацияланбайтынын дәлелдеді. Екі типтің үйлесімділігін тексеру, құрылымдық типтеу негізінде, тривиальды емес операция болып табылады, мысалы, бұрын тексерілген типтердің стегін сақтауды қажет етеді.
In structural typing, an element is considered to be compatible with another if, for each feature within the second element's type, a corresponding and identical feature exists in the first element's type. Some languages may differ on the details, such as whether the features must match in name. This definition is not symmetric, and includes subtype compatibility. Two types are considered to be identical if each is compatible with the other. For example, OCaml uses structural typing on methods for compatibility of object types. Go uses structural typing on methods to determine compatibility of a type with an interface. C++ template functions exhibit structural typing on type arguments. Haxe uses structural typing, but classes are not structurally subtyped. In languages which support subtype polymorphism, a similar dichotomy can be formed based on how the subtype relationship is defined. One type is a subtype of another if and only if it contains all the features of the base type, or subtypes thereof. The subtype may contain added features, such as members not present in the base type, or stronger invariants. A distinction exists between structural substitution for inferred and non inferred polymorphism. Some languages, such as Haskell, do not substitute structurally in the case where an expected type is declared (i. e., not inferred), e. g., only substitute for functions that are signature based polymorphic via type inference. Then it is not possible to accidentally subtype a non inferred type, although it may still be possible to provide an explicit conversion to a non inferred type, which is invoked implicitly. Structural subtyping is arguably more flexible than nominative subtyping, as it permits the creation of ad hoc types and protocols; in particular, it permits creation of a type which is a supertype of an existing type, without modifying the definition of the latter. However, this may not be desirable where the programmer wishes to create closed abstractions. A pitfall of structural typing versus nominative typing is that two separately defined types intended for different purposes, but accidentally holding the same properties (e. g. both composed of a pair of integers), could be considered the same type by the type system, simply because they happen to have identical structure. One way this can be avoided is by creating one algebraic data type for each use. In 1990, Cook, et al., proved that inheritance is not subtyping in structurally typed OO languages. Checking that two types are compatible, based on structural typing, is a non trivial operation, e. g., requires maintaining a stack of previous checked types.