Covariance and contravariance: con ict without a cause

ACM Transactions on Programming Languages and Systems, 1995

In type-theoretic research on object-oriented programming, the issue of “covariance versus contravariance” is a topic of continuing debate. In this short note we argue that covariance and contravariance appropriately characterize two distinct and independent mechanisms. The so-called contravariance rule correctly captures the subtyping relation (that relation which establishes which sets of functions can replace another given set in every context ). A covariant relation, instead, characterizes the specialization of code (i.e., the definition of new code which replaces old definitions in some particular cases ). Therefore, covariance and contravariance are not opposing views, but distinct concepts that each have their place in object-oriented systems. Both can (and should) be integrated in a type-safe manner in object-oriented languages. We also show that the independence of the two mechanisms is not characteristic of a particular model but is valid in general, since covariant specia...

Logical Method in Computer Science, 2021

Twenty years ago, in an article titled "Covariance and contravariance: conflict without a cause", I argued that covariant and contravariant specialization of method parameters in object-oriented programming had different purposes and deduced that, not only they could, but actually they should both coexist in the same language. In this work I reexamine the result of that article in the light of recent advances in (sub-)typing theory and programming languages, taking a fresh look at this old issue. Actually, the revamping of this problem is just an excuse for writing an essay that aims at explaining sophisticated type-theoretic concepts, in simple terms and by examples, to undergraduate computer science students and/or willing functional programmers. Finally, I took advantage of this opportunity to describe some undocumented advanced techniques of type-systems implementation that are known only to few insiders that dug in the code of some compilers: therefore, even expert language designers and implementers may find this work worth of reading. This is a corrected and enhanced version of the paper arXiv:1809.01427 published originally on Feb. 13, 2020. See Appendix B for differences in the versions.

1996

Object-oriented programming languages oopl's provide important support for today's large-scale software development projects. Unfortunately, the typing issues arising from the object-oriented features that provide this support are substantially di erent from those that arise in typing procedural languages. Attempts to adapt procedural type systems to object-oriented languages have resulted in languages like Simula, C++, and Object Pascal, which h a v e o v erly restrictive t ype systems. Among other things, the rigidity of these systems frequently force programmers to use type casts, which are a notorious source of hard-to-nd bugs. These restrictive type systems also mean that many programming idioms common to untyped oopl's such as Smalltalk are not typeable. One source of this lack of exibility is the con ation of subtyping and inheritance. Brie y, inheritance is an implementation technique in which new object de nitions may be given as incremental modi cations to existing de nitions. Subtyping concerns substitutivity: when can one object safely replace another? By tying subtyping to inheritance, existing oopl's greatly reduce the number of legal substitutions in a system, and hence their degree of polymorphism. Attempts to x this rigidity h a v e resulted in unsound type systems, most notably Ei el's.

Proceedings of the 10th ACM Symposium on Dynamic languages - DLS '14, 2014

Object-orientation relies on polymorphism to express behavioral variants. As opposed to traditional procedural design, explicit typebased conditionals should be avoided. This message is conveyed in introductory material on object orientation, as well as in objectoriented reengineering patterns. Is this principle followed in practice? In other words, are type predicates actually used in objectoriented software, and if so, to which extent?

Theory and Practice of Object Systems, 1995

This paper, which is partly tutorial in nature, summarizes some basic research goals in the study and development o f t yped objectoriented programming languages. These include both immediate repairs to problems with existing languages and the long-term development o f more exible and expressive, yet type-safe, approaches to program organization and design. The technical part of the paper is a summary and comparison of three object models from the literature. We conclude by discussing approaches to selected research problems, including changes in the type of a method from super class to sub class and the use of types that give information about the implementations as well as the interfaces of objects. Such implementation types seem essential for adequate typing of binary operations on objects, for example.

Draft available at http://se. ethz. ch/meyer, 2003

Goals of expressiveness and flexibility in typed object-oriented programming suggest a “covariant” type policy, where routine redefinitions can change the types of both arguments and results in the same direction as the inheritance hierarchy. Unfortunately, a careless covariant policy, when combined with polymorphism, genericity and dynamic binding—other OO mechanisms that are just as fundamental—may lead to run-time type violations known as catcalls. We present a new solution to this problem, resulting from ...

Citeseer, 1999

In this thesis we study some object-oriented mechanisms from the type system perspective. Our starting point is the axiomatic model of Fisher, Honsell and Mitchell, the Lambda Calculus of Objects. Following the path of recent researches on the topic, we show how some object-based language features can be happily modeled within some functional calculi, proved sound with respect to the message-not-understood error. Then, we approach the more complicated problem of modeling class constructs, presenting two proposals and discussing their respective qualities and drawbacks, together with some future directions we would like to follow to try to better understand classbased languages. precious comments and all of the discussions we had together on objects. A special thank goes to Betti Venneri (University of Firenze), for her encouragement since she has been the supervisor for my master thesis when she was still in Torino. My gratitude goes then to my external referees, Giuseppe Castagna (ENS, Paris) and Sophia Drossopoulou (Imperial College, London), for their kindness in accepting to read my manuscript and for their precious suggestions that helped me improving the presentation of my work. Last but not least, I would like to mention all the people I met during my academic path that made my life easier with their friendship and their support (following again the temporal order in which I met them for the rst time

1996

This paper addresses the issue of giving a formal semantics to an object-oriented programming and specification language. Object-oriented constructs considered are objects with attributes and methods, encapsulation of attributes, subtyping, bounded type parameters, classes, and inheritance. Classes are distinguished from object types. Besides usual imperative statements, specification statements are included. Specification statements allow changes of variables to be described by a predicate. They are abstract in the sense that they are non-executable. Specification statements may appear in method bodies of classes, leading to abstract classes. The motivation for this approach is that abstract classes can be used for problem-oriented specification in early stages and later refined to efficient implementations. Various refinement calculi provide laws for procedural and data refinement, which can be used here for class refinement. This paper, however, focuses on the semantics of object-oriented programs and specifications and gives some examples of abstract and concrete classes. The semantics is given by a translation of the constructs into the type system F≤, an extension of the simple typed λ-calculus by subtyping and parametric polymorphism: The state of a program is represented by a record. A state predicate is a Boolean valued function from states. Statements, both abstract and concrete, are represented by predicate transformers, i. e. higher order functions mapping state predicates (postconditions) to state predicates (preconditions). Objects are represented by records of statements (the methods) operating on a record of attributes, where the attributes are hidden by existential quantification. Classes are understood as templates for the creation of objects. Classes are represented by records. Inheritance amounts to record overwriting. Subtyping and parametric polymorphism, e. g. for the parameterization of classes by types, are already present in F≤. The advantage of this semantic by translation is that it builds on the features already provided by F≤ (which are all used). Hence no direct reference to the model underlying F≤ needs to be made; a summary of the syntax and rules of F≤ is given.

2003

In this paper we discuss some of the remaining problems in the design of static type systems for object-oriented programming languages. We look at typing problems involved in writing a simple interpreter as a good example of a simple problem leading to difficult typing issues. The difficulties encountered seem to arise in situations where a programmer desires to simultaneously refine mutually interdependent classes and object types.

ACM SIGPLAN Notices, 1990

This paper is concerned with the relation between subtyping and subclassing and their influence on programming language design. Traditionally subclassing as introduced by Simula has also been used for defining a hierarchical type system. The type system of a language can be characterized as strong or weak and the type checking mechanism as static or dynamic . Parameterized classes in combination with a hierarchical type-system is an example of a language construct that is known to create complicated type checking situations. In this paper these situations are analyzed and several different solutions are found. It is argued that an approach with a combination of static and dynamic type checking gives a reasonable balance also here. It is also concluded that this approach makes it possible to base the type system on the class/subclass mechanism.