Why Nominal-Typing Matters in Object-Oriented Programming Moez A. AbdelGawad College of Mathematics and Econometrics, Hunan University Changsha 410082, Hunan, P.R. China Informatics Research Institute, SRTA-City New Borg ElArab, Alexandria, Egypt [email protected] January 1, 2018 Abstract type systems. Recently, a domain-theoretic model of nominally-typed OOP was compared to well-known The statements ‘inheritance is not subtyping’ and models of structurally-typed OOP. Combined, these ‘mainstream OO languages unnecessarily place re- comparisons provide both a clear technical account strictions over inheritance’ have rippled as mantras and a deep mathematical account of the relation be- through the PL research community for years. Many tween nominal and structural OO type systems that mainstream OO developers and OO language design- have not been presented before, and they help demon- ers, however, do not accept these statements. In strate the key value of nominal typing and nominal nominally-typed OO languages that these developers subtyping to OO developers and language designers. and language designers are dearly familiar with, in- We believe a clearer understanding of the key se- heritance simply is subtyping; and they believe OO mantic advantage of pure nominal OO typing over type inheritance is an inherently nominal notion, not pure structural OO typing can help remedy the ex- a structural one. isting schism. We believe future foundational OO Nominally-typed OO languages, such as Java, C#, PL research, to further its relevance to mainstream C++, and Scala, are among the most used program- OOP, should be based less on structural models of OOP and more on nominal ones instead. arXiv:1606.03809v3 [cs.PL] 29 Dec 2017 ming languages today. However, the value of nominal typing to mainstream OO developers, as a means for designing robust OO software, seems to be in wait for full appreciation among PL researchers—thereby per- 1 Introduction petuating an unnecessary schism between many OO developers and language designers and many OO PL In 1990, Cook et al. shocked the programming lan- researchers, with each side discounting, if not even guages (PL) research community by declaring that, disregarding, the views of the other. in object-oriented programming, ‘inheritance is not In this essay we strengthen and complement earlier subtyping,’ meaning there is no one-to-one corre- efforts to demonstrate the semantic value of nomi- spondence between type inheritance and subtyping nal typing by presenting a technical comparison be- in OO programming languages, further adding that tween nominal OO type systems and structural OO mainstream OO languages unnecessarily ‘place re- 1 strictions over inheritance.’ Over the years, these and interface names and trait names in OO languages statements rippled, as mantras, through the PL re- that support these notions—are used as type names search community. in nominally-typed OO languages. Class—and inter- To this day, however, many mainstream OO de- face and trait—behavioral contracts, typically writ- velopers and OO language designers cannot digest or ten informally in code documentation comments, are accept not identifying type inheritance with subtyp- specifications of the behavioral design intentions of ing. Simply, the statement of Cook et al. is not true OO software developers. In nominally-typed OOP, a in nominally-typed OO languages that these develop- reference to a class (or interface or trait) name is in- ers and language designers are dearly familiar with. variably considered a reference to the associated con- Further, they see that the so-called “restriction” of tract too. Given this association of type names to type inheritance in nominally-typed OO languages is corresponding behavioral contracts, nominal typing strongly justified, or, more so, that a structural view allows associating types of objects with (formal or in- of inheritance is in fact an unjustified redefinition of formal) behavioral contracts. type inheritance, which they view as an inherently By using type names in their code, OO develop- nominal notion. ers using nominally-typed OO languages have a sim- Nominally-typed OO languages are among the ple way to refer to the corresponding contracts— top most-used programming languages today. Ex- referring to them as richer specifications of object amples of nominally-typed OO languages include state and behavior that can be checked statically and many industrial-strength mainstream OO program- that can be used during runtime. This readily access ming languages such as Java [44], C# [1], C++ [2], to richer object specifications—which cannot be ex- and Scala [61]. Nominally-typed OO languages have pressed in a natural way using non-nominal (a.k.a., remained among the top most-used programming structural) record types that, by definition, include languages for over a decade [14, 5]. And, even by the no class names information—makes nominally typed most conservative measures, these languages are ex- OO languages closer to being semantically typed lan- pected to remain among the top most-used OO pro- guages than structurally typed OO languages are. gramming languages in the near future, if not the far The first mathematical models of OOP to gain one, too. widespread recognition among programming lan- In spite of this, the value of nominal typing and guages (PL) researchers were developed while OOP nominal subtyping to mainstream OO developers, as was making its first steps into mainstream computer a means for designing robust OO software that can programming. (See Section 2.) These early models be readily understood and maintained, as well as the were structural models of OOP. As the developers value of properties of OO type systems that depend of these models themselves (e.g., Cardelli) explained, on nominality to them (such as the identification of this was due to influence from functional program- type inheritance with subtyping), seem to be not yet ming research extant at that time. These models of fully appreciated among OO PL researchers. This OOP, thus, reflected a view of OOP that does not has led to a continuing tension and schism between include class names information. two large and significant communities: many main- Being structural, objects were viewed in these mod- stream OO developers and OO language designers, on els simply as being records (of functions). Object one side, and many OO PL researchers, on the other types, in accordance, were viewed as record types, side, with each of both sides discounting, and even where the type of an object only specifies the struc- disregarding, the views and opinions of the other. ture of the object, meaning that object types carry In nominally-typed (a.k.a., nominatively-typed) information only on the names of the members of ob- OO languages, objects and their types are nomi- jects (i.e., fields and methods) and, inductively, on nal, meaning that objects and their types carry class the (structural) types of those members. Examples names information as part of the meaning of objects of structurally-typed OO languages include lesser- and of the meaning of their types. Class names— known languages such as O’Caml [48], Modula-3 [27], 2 Moby [39], PolyTOIL [21], and Strongtalk [19].1 In Given that structural typing, more or less, is under- pure structurally-typed OO languages, class names stood well among PL researchers, in Section 3 we di- information (also called nominal information) is not rectly demonstrate the value of behavioral contracts used as part of the identity of objects and their types, and nominal typing in mainstream nominally-typed neither during static type checking nor at runtime. OO languages using a comparison, followed by a dis- Accordingly, nominal information is missing in struc- cussion of the comparison. In Section 3.1 we first tural mathematical models of OOP. discuss, in some detail, the value of contracts and The main practical advantage of structural typing the value of identifying inheritance with subtyping in over nominal typing in OO languages seems to be mainstream OO software design. Then, using code their “flexibility,” i.e., the ability in a structurally- examples, in Section 3.2 and Section 3.3 we compare typed OO language to have supertypes get defined nominally-typed OO type systems and structurally- “after the fact” (i.e., after their subtypes are already typed ones to more vividly illustrate the main tech- defined). In light of mainstream OO developers of nical differences between them. We then conclude in statically-typed OO languages not adopting struc- Section 3.4 by discussing the nominal and structural tural typing, the “inflexibility” of nominally-typed views of type names and of recursive-types, and the OO languages seems not to be enough justification for importance of recursive types in mainstream OOP. wider use of structural typing, particularly in light of We conclude the essay by summarizing our find- the advantages of nominal typing we discuss in this ings, and making some final remarks, in Section 4. essay. We attempt thus in this essay to further close the gap that exists between programming language 2 Related Work researchers who maintain a structurally-typed view of OOP (and who believe in conclusions based on Even though object-oriented programming emerged this view, such as inheritance and subtyping not be- in the 1960s, and got mature and well-established ing in one-to-one correspondence) and mainstream in mainstream software development in the 1980s, OO software developers and OO language design- the differences between nominally-typed and ers who maintain a nominally-typed view of OO structurally-typed OO programming languages software (and who, accordingly, reject conclusions started getting discussed by PL researchers only based on the structural view) by giving a precise in the 1990s [53, 65, 68]. In spite of an early hint technical account of the relation between nominal by Cardelli (see below), the value of investigating and structural OO type systems.