Classes and Types in an Ideal Object-Oriented …ducour/Publis/shenyang-classtype.pdf · Aristotle...

Classes and Types in an IdealObject-Oriented Programming Language

Roland Ducournau

LIRMM – Université de Montpellier & CNRS

东北大学, 沈阳市 – April 2016

R. Ducournau (LIRMM) Ideal Classes and Types 沈阳市, 2016 1 / 88

Motivation: the good news

Object-orientationis now universal for programming, modelling, ..

Mature theory and technology≈ 24 centuries after Aristotle (350 BC),≈ half a century after Simula (1967),≈ 3 decades ago: first mainstream languages (Eiffel, C++)≈ 2 decades ago: Java, then C] and Scala

* Likely the greatest success of the last century!


Motivation: the bad news

The greatest failure of the last century?The object-oriented programming languages!

Each one, individually!All together!

The same featuresare specified differently,as if programming languages were works of art!

* The Babel Tower!


My thesis

Plato’s idealsapply to Circle, Tree, ..apply to Programming Languages, too

* The ideal Object-Oriented Programming Language exists


My thesis

Arguments taken from ...philosophy (Aristotle)ontology (object metamodel)necessity (Occam’s razor)mathematics (type and set theory, logic)empiricismcommon sense


Plan

Plan

1 Classes and inheritance

2 Types and subtyping

3 Genericity

4 Conclusions and propects


Classes and inheritance

Plan

1 Classes and inheritanceAristotelian semanticsClass and property metamodelMultiple inheritance conflictsMethod combinationAbout existing languages


3 Genericity



Classes and inheritance Aristotelian semantics

Object-orientation vs knowledgerepresentation

* an object-oriented model is a representation of the real-worldTM



OO vs KR: PhilosophersMortal

Human

Greek Philosopher Chinese

Greekphilosopher philosopher

Chinese

Aristotle Plato Kongfuzi Lao Tseu



OO vs KR: Philosophers

classes

instances

Mortal

Human



Chinese




OO vs KR: Philosophers

instance of

subclass ofclasses

instances

Mortal

Human



Chinese




Philosophers

Aristotle (Αριστοτέλης , 384-322 BC) founded logicPlato (Πλάτων , 427-348 BC) promoted the existence of ideas孔子 (Kongfuzi, 551-479 BC)老子 (Lao Tseu)庄子 (Zhuangzi) a butterfly dream

* in the XX◦ century jargon, ideas are first-class objects



Aristotelian semantics (1/3)

The extension of a class is the set of its instances

Foundation syllogism

Humans are Mortals孔子 is a Human孔子 is a Mortal

Human ≺ Mortal孔子 ∈ Ext(Human)孔子 ∈ Ext(Mortal)

Subclassing = specialization = inclusion of extensions* Instances of the subclass are instances of the superclass

B ≺ A⇒ Ext(B) ⊂ Ext(A)




The intension of a class is a set of properties declared for its instances

Inheritance of propertiesan instance of a class has all the properties declared by the classas a Human, 孔子 is a Mortal

* 孔子 has all the properties declared by Mortal

Inheritance is implied by specialization* The subclass inherits the properties declared in the superclass

B ≺ A⇒ Int(A) ⊂ Int(B)




My answers to objectionsin Logo, a Turtle is a Pointthere is no specialization in the real worldTM

* but specialization is in the artefactso-called implementation inheritance

* a bad practice resulting from an erroneous model


Classes and inheritance Class and property metamodel

An object model of the object model (1/3)

Object-orientation is part of the real worldTM

* object-orientation can be used for representing object-orientation

An object meta-modela UML modelmodelling the entities of object-orientation,i.e. classes, associations, attributes, methods, ...with classes, associations, attributes, methods, ...




Motivationsmandatory for all metaprograms(e.g. compilers, VMs, IDEs)provides an ontology of object orientationwith unambiguous specificationsby getting rid of names




Language ambiguitiesnatural languages are inherently ambiguous* plays on wordsprogramming languages, although formal, are ambiguous, too

because they serve as man-machine interfacesthrough various names

* compilers don’t joke!

Foundation requirement* in the modelled program, each occurrence of the name of amodelled entity must denote a single instance of the metamodel



12

class A {foo() {...}

}

a class, named Aa method named foo(), defined in A

34

5

class B extends A {foo() {...}

bar() {...}}

a class named B, subclass of Aa method named foo(), defined in B

redefining foo() of Aa method named bar(), defined in B

136

7

A x;B y;x.foo();

y.bar();

a type annotation with class Aa type annotation with class Ba message foo() introduced in A

sent to x with late bindinga message bar() introduced in B




A single class for classesfor all usages: declarations, type annotations and new

Two classes for propertiesa class for local properties, implementations defined in a classa class for global properties, messages invoked from the code

What are properties?methods, attributesformal type parameters, virtual types, ...



*

*

redef

ines

*

1

named nam

ed

1

*

*

*

specializes

1

*

*

1

*

*

belongs to

*

1

know

s

introduce

sdefines

PropertyGlobal Local

Property

name : Stringtype : Type

Name

Class

name : String



12

345

1367


}

class B extends A {foo() {...}bar() {...}

}

A x;B y;x.foo();y.bar();

A : Class

name=A

1



12

345

1367


}


}


name = foo

A:foo::A :LocalP

defines

2

A : Class

name=A

1



12

345

1367


}


}


name = foo

A:foo :GlobalP

6

knows

introduces belo

ngs

to

name = foo

A:foo::A :LocalP

defines

2

A : Class

name=A

1



12

345

1367


}


}


B : Class

name=B

know

s

3 sp

ecia

lizes

name = foo

A:foo :GlobalP

6

knows

introduces belo

ngs

to

name = foo

A:foo::A :LocalP

defines

2

A : Class

name=A

1



12

345

1367


}


}


name = foo

A:foo::B :LocalP

red

efi

nes

belongs to

4

defines

B : Class

name=B

know

s

3 sp

ecia

lizes

name = foo

A:foo :GlobalP

6

knows

introduces belo

ngs

to

name = foo

A:foo::A :LocalP

defines

2

A : Class

name=A

1



12

345

1367


}


}


name = bar

B:bar::B :LocalP

defines 5

name = foo

A:foo::B :LocalP

red

efi

nes

belongs to

4

defines

B : Class

name=B

know

s

3 sp

ecia

lizes

name = foo

A:foo :GlobalP

6

knows

introduces belo

ngs

to

name = foo

A:foo::A :LocalP

defines

2

A : Class

name=A

1



12

345

1367


}


}


name = bar

B:bar :GlobalP

knows

introduces

7

belongs to

name = bar

B:bar::B :LocalP

defines 5

name = foo

A:foo::B :LocalP

red

efi

nes

belongs to

4

defines

B : Class

name=B

know

s

3 sp

ecia

lizes

name = foo

A:foo :GlobalP

6

knows

introduces belo

ngs

to

name = foo

A:foo::A :LocalP

defines

2

A : Class

name=A

1



Metamodeling semantics

Disambiguating name conflictsIn two situations

with multiple inheritancewith static overloading

* by substituting an instance of local/global propertyto each property name, even when it seems ambiguous

Actual ambiguities = compiler errorsWhen this substitution is not possible (several candidates)


Classes and inheritance Multiple inheritance conflicts

Motivation for multiple inheritance (1/2)

Multiple inheritance providesincreased expressivityimproved reuse

given a class A providing a service fooand a class B providing a service barboth developped independently of each other(apart from common superclasses)

* define a common subclass C providing both services



Motivation for multiple inheritance (2/2)

In static typingThere is no language without

full multiple inheritance (C++, Eiffel),or mixins (Scala),or at least multiple subtyping (Java, C], Ada 2005)



Multiple inheritance conflicts (1/5)

Conflicts of two kindsbetween two global properties with the same namebetween two local properties of the same global property

* plus the method combination case




Researcher

laboratorydepartment department

university

Teacher

Person

nameaddress




Researcher


university

Teacher

Person

nameaddress Researcher x;

x.department; // OK

Teacher y;y.department // OK




Teacher−Researcher

Researcher


university

Teacher

Person

nameaddress Researcher x;

x.department; // OK

Teacher y;y.department // OK




Teacher−Researcher

Researcher


university

Teacher

Person

nameaddress

Teacher-Researcher z;

Researcher x=z;x.department; // OK

Teacher y=z;y.department // OK

z.department // KO



name=Person

P : Class



name = department

R:dpt : GlobalP

name = department

R:dpt::R : LocalP

R : Class

name=Researcher

introduces

knows

defines

be

lon

gs

to

specializ

esname=Person

P : Class



T:dpt::T : LocalP

name = department

name = department

T:dpt : GlobalP

specializes

knows

defines

be

lon

gs

to name=Teacher

T : Class

introduces

name=Person

P : Class



T:dpt::T : LocalP

name = department

name = department

T:dpt : GlobalP

specializes

knows

defines

be

lon

gs

to name=Teacher

T : Class

introducesname = department

R:dpt : GlobalP

name = department

R:dpt::R : LocalP

R : Class

name=Researcher

introduces

knows

defines

be

lon

gs

to

specializ

esname=Person

P : Class



name=TR

TR : Class

specializes specializes

kn

ow

s

T:dpt::T : LocalP

name = department

name = department

T:dpt : GlobalP

specializes

knows

defines

be

lon

gs

to name=Teacher

T : Class

introducesname = department

R:dpt : GlobalP

name = department

R:dpt::R : LocalP

R : Class

name=Researcher

introduces

knows

defines

be

lon

gs

to

specializ

esname=Person

P : Class




Diagnosisconflict between two global properties with the same name

Solution: Fully Qualified Namesshort names are used in most situationsnames qualified with the introduction classused when a conflict occurs

* a global property is introduced by a single classstatic typing required



short names




z.department // KO



short names fully qualified names




z.department // KO

means x.Researcher:department

means y.Teacher:department

must be disambiguated withz.Teacher:department

or z.Researcher:departmentthe programmer should know!




area = (diagonal1

* diagonal2)/2

Rhombus

diagonal2

diagonal1

Quadrilateral

area = ...

length* width

area =

Square

length

Rectangle

width



name = area

Q:area::Q : LocalP

Q : Class

name=Q

kn

ow

s

intr

od

uc

es

name = area

Q:area : GlobalP

defin

es



Re : Class

name=Re

name = area

Q:area::Re : LocalP

specializ

es

knows

definesbel

ongs

to

red

efi

nes

name = area

Q:area::Q : LocalP

Q : Class

name=Q

kn

ow

s

intr

od

uc

es

name = area

Q:area : GlobalP

defin

es



name = area

Q:area::Rh : LocalP

defines

Rh : Class

name=Rh

specializes

knows

red

efi

ne

s

belo

ngs to

red

efi

nes

Re : Class

name=Re

name = area

Q:area::Re : LocalP

specializ

es

knows

definesbel

ongs

to

name = area

Q:area::Q : LocalP

Q : Class

name=Q

kn

ow

s

intr

od

uc

es

name = area

Q:area : GlobalP

defin

es



name=S

S : Class

specializes

kn

ow

s

specializes

name = area

Q:area::Rh : LocalP

defines

Rh : Class

name=Rh

specializes

knows

red

efi

ne

s

belo

ngs to

red

efi

nes

Re : Class

name=Re

name = area

Q:area::Re : LocalP

specializ

es

knows

definesbel

ongs

to

name = area

Q:area::Q : LocalP

Q : Class

name=Q

kn

ow

s

intr

od

uc

es

name = area

Q:area : GlobalP

defin

es




Diagnosisconflict between two local properties of the same global propertynone more specific than the other

Solution* redefinition in the class where the conflict occurs




2sidearea =

area = (diagonal1

* diagonal2)/2

Rhombus

diagonal2

diagonal1

Quadrilateral

area = ...

length* width

area =

Square

length

Rectangle

width


Classes and inheritance Method combination

Monotonicity vs redefinition

Aristotelian logic is monotonic* a Human must behave like a Mortal

Redefinition is non-monotonic* redefining a method yields non-monotonicity

Method combination = Call to supera way to recover monotonicity

* a Human behaves like a Mortal, with extra behaviour



Method combination conflicts

area = super

area = (diagonal1

* diagonal2)/2

Rhombus

diagonal2

diagonal1

Quadrilateral

area = ...

length* width

area =

Square

length

Rectangle

width



Method combination conflicts

area = super

area = (diagonal1

* diagonal2)/2

Rhombus

diagonal2

diagonal1

Quadrilateral

area = ...

length* width

area =

Square

length

Rectangle

width

?



A wrong solution: static super calls

B

A::foofoo = {.. ..}

A

foo = { ... }

A::foofoo = {.. ..}

C

D

B::foofoo = {..

C::foo ..}

like C++ or Eiffel



A wrong solution: static super calls

B

A::foofoo = {.. ..}

A

foo = { ... }

A::foofoo = {.. ..}

C

D

B::foofoo = {..

C::foo ..}

like C++ or Eiffel* A::foo evaluated twice

repeated inheritance



The right solution: linearization (1/2)

B

foo = {.. ..}super

A

foo = { ... }

foo = {.. ..}

C

super

D

foo = {.. super ..}

Specialization = a partial order




B

foo = {.. ..}super

A

foo = { ... }

foo = {.. ..}

C

super

D

foo = {.. super ..}

Linearization = a total order* A::foo evaluated once

non-repeated inheritance




Principlelinear extension of the specialization partial ordermonotonic

* order preserved by specializationan algorithm called C3 (used in Python)


Classes and inheritance About existing languages

With restricted multiple inheritance (1/3)

Multiple subtyping (Java, C])no problem with local property conflicts, nor method combination

* except with default methods in Java 8ad hoc solution for global property conflicts in C]

no solution for global property conflicts in Java

Multiple subtyping could be well-specified




Mixins/Traitssame problems as with full multiple inheritance

global property conflictsmethod combination

* if mixins were the answer, what was the question?* just add unnecessary asymmetry between classes and traits




The Scala caseno solution for global property conflicts (like in Java)linearization-based method combination, but not C3

The questionHow to easily implement “multiple inheritance” in multiple-subtypingruntime systems?



With full multiple inheritance (1/2)

C++ virtual inheritanceright solution for global attribute conflictsno solution for global method conflicts

* two distinct attributes for a single accessor!method combination with static calls and repeated inheritancelinearization used for constructor/destructor combinationbut not C3

C++ non-virtual inheritancerepeated inheritance for non-conflicting global attributes

* an abomination



With full multiple inheritance (2/2)

Eiffelad hoc solution for global property conflicts, with renamingmethod combination with static calls and repeated inheritance

With dynamic typing (CLOS, Python)no solution for global property conflictslinearization-based method combinationC3 default linearization only in Pythonpossibility to define metaclasses using C3 in CLOS



The ideal of multiple inheritance

fully symmetricno distinction between classes and traitsthe same for methods, attributes, virtual types, type parameters

metamodeling semanticswith fully qualified names for global propertieswithout any repetition

local property conflicts solved by redefinitionmethod combination using the C3 linearization



References on multiple inheritance

with Jean Privat: Meta-Modeling Semantics of Multiple InheritanceScience of Computing Programming, 2011.with Michel Habib, Marianne Huchard and Marie-Laure Mugnier:Proposal for a monotonic multiple inheritance linearization.In Proc. OOPSLA’94. 1994.Monotonic conflict resolution mechanisms for inheritance.In Proc. OOPSLA’92, 1992


Types and subtyping

Plan


2 Types and subtypingClasses vs typesSpecialization vs subtypingStatic overloading

3 Genericity



Types and subtyping Classes vs types

Classes vs types (1/2)

Different rolesclasses declare properties and create instancestypes serve as annotations in the code

* allow the compiler to ensure the code is type safe

Nominal vs structural typesa nominal type is a symbol with explicit subtypinga structural type is a record of named signatures, with implicitsubtyping


Types and subtyping Classes vs types

Classes vs types (2/2)

Mainstream position (C++, Java, C], Scala, Eiffel, ..)Besides higher-order types:

classes are nominal typessubtyping is implied by class specialization

The OCAML exception* types are purely structural


Types and subtyping Specialization vs subtyping

Specialization vs subtyping (1/5)

Subtyping is substitutability (B. Liskov)

Specialization implies subtypingIFF redefinition satisfies the contravariance rule

return type must be redefined covariantlyparameter types must be redefined contravariantly

* type safe




Mainstream position (C++, Java, Scala, ...)return types are covariantparameter types are invariant

ExceptionsC] & Java 1.4: return types are invariant* no reason at allEiffel: parameter types are covariant* type unsafeOCAML: parameter types are contravariant




Motivations of the choicecovariance because of the mad cow exampleinvariance because

contravariance is useless in practicestatic overloading was preexisting object-orientation

contravariance because of structural types




Animal

eat(Food)

Food

Cow

eat(Grass)

Grass

Animal x ;Food y ;x.eat(y);

* don’t panic, but type errors are in the real worldTM




Animal

eat(Food)

Food

Cow

eat(Grass)

Grass MeatMeal

Animal x = new Cow();Food y = new MeatMeal();x.eat(y); // runtime type error

* don’t panic, but type errors are in the real worldTM




What is my ideal?invariance of both parameter and return typescovariance through virtual types


Types and subtyping Static overloading

Static overloading (1/3)

When parameter types are invariant,* there is room for static overloading

Principlea name denoting different entities in a common contextdisambiguated with static typesoriginates in pre-object languages like PL/1 and C



Mal nommer les choses,c’est ajouter au malheur du mondeMisnaming things adds to the world’s misfortunes(Albert Camus)

Albert Camus a French writer and philosopher (1913-60)Peyo a Belgian author of comic strips (1928-92)

creator of the SchtroumpfsSchtroumpfs small characters whose language

has a single noun and verb: “schtroumpf”



Misnaming things addsto the world’s misfortunes

in the context of a picture, even small children can understand!



Schtroumpfing schtroumpfs schtroumpfsto the schtroumpf’s schtroumpfs

in the context of a picture, even small children can understand!


B

foo(T)

A

foo(U) U <: TB xU y

x.foo(y)C++Java 1.4Java 1.5ScalaC]

B

foo(T)

A

foo(U) U <: TB xU y

x.foo(y)C++ foo(T)Java 1.4 errorJava 1.5 foo(U)Scala errorC] foo(T)

bar(U)

bar(T)

B

foo(T)

A

foo(U) U <: TB xU yT z = new U

x.foo(y) x.bar(z)C++ foo(T) errorJava 1.4 error bar(T)Java 1.5 foo(U) bar(T)Scala error bar(T)C] foo(T) bar(T)

bar(U)

bar(T)

B

foo(T)

A

foo(U) U <: TB xU yT z = new U

Confusion with covariancecontravariance or multiple selection

x.foo(y) x.bar(z)Eiffel error error

OCAML foo(T) errorintuition — bar(U)



6 languages* 6 different specifications + the intuition

* it cannot be a sane language feature



*

*

redef

ines

*

1

named nam

ed

1

*

*

*

specializes

1

*

*

1

*

*

belongs to

*

1

know

s

introduce

sdefines

PropertyGlobal Local

Property

name : Stringtype : Type

Name

Class

name : String



Static overloading in the metamodel

T : Class

name=T

U : Class

name=U

sp

ecia

lizes




A : Class

name=A

T : Class

name=T

U : Class

name=U

sp

ecia

lizes




definesA:bar(T)::A : LocalPA : Class

name=A

T : Class

name=T

U : Class

name=U

sp

ecia

lizes




namebar(T) : Name

name=bartypedefines

A:bar(T)::A : LocalPA : Class

name=A

T : Class

name=T

U : Class

name=U

sp

ecia

lizes




introduces

A:bar(T) : GlobalP

knows

name

belongs to

namebar(T) : Name

name=bartypedefines


name=A

T : Class

name=T

U : Class

name=U

sp

ecia

lizes



Static overloading in the metamodelsp

ecia

lizes

B : Class

name=B

knows

introduces

knows

A:bar(T) : GlobalPname

belongs to

name typebar(T) : Name

name=bardefines


name=A

sp

ecia

lizes

U : Class

name=U

T : Class

name=T




definesB:bar(U)::B : LocalP

sp

ecia

lizes

B : Class

name=B

knows

introduces

knows


belongs to


name=bardefines


name=A

sp

ecia

lizes

U : Class

name=U

T : Class

name=T




name typebar(U) : Name

name=bardefines

B:bar(U)::B : LocalP

sp

ecia

lizes

B : Class

name=B

knows

introduces

knows


belongs to


name=bardefines


name=A

sp

ecia

lizes

U : Class

name=U

T : Class

name=T




introduces

knows

B:bar(U) : GlobalP

belongs to

name


name=bardefines


sp

ecia

lizes

B : Class

name=B

knows

introduces

knows


belongs to


name=bardefines


name=A

sp

ecia

lizes

U : Class

name=U

T : Class

name=T


The right semantics (1/2)

At compile-type1 select all the global methods, known by the receiver’s static type,

with parameter static types compatible with the callsay foo(T) and foo(U)

2 select among them the single most specificif U <: T, foo(U) is more specific than foo(T)

3 compilation error when there are several most specificeg baz(T,U) and baz(U,T)

At run-type = late bindingselect in the global property the most specific local propertyfor the receiver’s dynamic type


The right semantics (2/2)

That of Java 1.5specificity does not involve the introduction or definition classes(as in Java 1.4 or Scala)a local property of a given global property doesn’t mask a localproperty of another global property, as in C++ and C]eg foo(T) in B doesn’t mask foo(U) in A



Avoid overloading by renaming

introduces

knows

B:bar(U) : GlobalP

belongs to

name


name=bardefines


sp

ecia

lizes

B : Class

name=B

knows

introduces

knows


belongs to


name=bardefines


name=A

sp

ecia

lizes

U : Class

name=U

T : Class

name=T



Avoid overloading by renaming

introduces

knows

B:bar(U) : GlobalP

belongs to

name


name=bardefines


sp

ecia

lizes

B : Class

name=B

knows

introduces

knows


belongs to


name=bardefines


name=A

name= barU

barU(U):NamebarU(U)B: ::B:LocalP

barU(U)B: :GlobalP

name= barT

barT(T) :NamebarT(T)A: ::A :LocalP

barT(T)A: :GlobalP

sp

ecia

lizes

U : Class

name=U

T : Class

name=T



The right specifications

exclude overloading from the language specifications(as in Eiffel or Nit),otherwise, apply the right semantics (Java 1.5)but don’t use it

* instead, rename!



The Schtroumpf project

Reductio ad absurdumselect some mainstream language with static overloading

C++, Java, C], Scala, not Eiffelselect some large-scale project written in this languagerename all methods in the project classes as either foo or bar

* in case of conflict, add an extra, unused parameter

Variant* develop an Eclipse plugin that does this renaming, automatically


Genericity

Plan



3 GenericityGenericity vs subtypingVariance annotations



Genericity Genericity vs subtyping

Generic vs object-oriented programming

Genericity is not object-orientedtwo almost orthogonal constructs

Genericity is now universalIn static typing

object-oriented languages are now generic(Eiffel, C++, Java, C], ...)generic languages (Ada) are now object-oriented



Generic vs object-oriented programming

Genericity + subtyping ⇒ troubleshard to specifyhard to understand and usehard to implement efficiently



Specifications by implementation

At least 3 versionsheterogeneous pure textual substitution (C++)

* no recursive types + code explosionhomogeneous type erasure and code sharing (Java 1.5, Scala)

* limited expressivity, unsafe casts, inefficient boxingmixed code shared or specialized, with runtime types (C])

* best tradeoff expressivity-efficiency-safety



Constrained genericity

At least 3 specifications of contraintsnone (C++)* no checking before instantiation* (recently) notion of conceptformal type parameters bounded by subtyping* simple to understand and userecursive bound (F-bounded) (Java, C], Scala, Eiffel, ...)* powerful but harder to understandallows to clone isomorphic structures


Genericity and (co)variance

PrincipleCup<茶> is not a subtype of Cup<Drink>

But many unsafeties ...generalized covariance (Eiffel)covariance of arrays (Java, C])casts with type erasure (Java, Scala)

Safe variance annotationsat definition-time (Scala, C] only for interfaces)at use-time (wildcards Java, Scala)


Array covariance

Cats are not dogsCat[] x;...Animal[] y;y = x; // dangerous but compiledy[i] = new Dog(); // compiled but runtime exception


Type erasure = Alzheimer

Cats are not dogs (re)Stack<Cat> x;...Stack<Dog> y;y = (Stack<Dog>)x; // stupid but compiledy.push(new Dog); // type is erased! Alzheimer...Cat z = x.pop(); // late exception

* bad traceability of errors

Genericity Variance annotations

Variance

Variance positionsclass Stack<T> {

T pop () {..} // covariant positionpush(T t) {..} // contravariant position

}* more complex rules when T is nested

Variance-variance can be considered

if T does not occur in a -variant positionif such occurrences are excluded from the type interface


Variance




VarianceCo-variance can be considered

if T does not occur in a contra-variant positionif such occurrences are excluded from the type interface



Variance




VarianceContra-variance can be considered

if T does not occur in a co-variant positionif such occurrences are excluded from the type interface


Variance annotations (1/3)

Use-site covarianceStack<? extends Animal> s = new Stack<Cat>();Animal a = s.pop(); // OKs.push(a); // KO

* interface restricted to methods wherethe type parameter is not in a contravariant position

* useful for exporting “almost read-only” collections

Use-site contravarianceStack<? super Cat> s = new Stack<Animal>();Animal a = s.pop(); // KOObject o = s.pop(); // OKs.push(new Cat()); // OK

* interface restricted to methods wherethe type parameter is not in a covariant positionor is replaced by the parameter bound

* counter-intuitive and rarely used, apart from Comparable

Definition-site varianceclass ImmutableContainer<+ T>

{ T get() ;}class Container<T> inherit ImmutableContainer<T>

{ put(T) ;}

* with + the type parameter is covariantand cannot be used in a contravariant position

useful for exporting “actual read-only” collections

Definition-site varianceclass ImmutableContainer<+ T>

{ T get() ;}class Container<T> inherit ImmutableContainer<T>

{ put(T) ;}

* with – the type parameter is contravariantand cannot be used in a covariant position

counter-intuitive and rarely used

Contravariance and recursive bound

interface Comparable<T extends Comparable<T>>class OrderedSet<T extends Comparable<T>>class A implements Comparable<A>OrderedSet<A> // OK

class B extends A// B implements Comparable<A>

OrderedSet //// B doesn’t implement Comparable

class B extends A // OK// B implements Comparable<A>

OrderedSet // KO// B doesn’t implement Comparable

class B extends A implements Comparable // KO// B cannot implement both

OrderedSet // KO

interface Comparable<T extends Comparable<T>>class OrderedSet<T extends Comparable<? super T>> Javaclass A implements Comparable<A>OrderedSet<A> // OK

class B extends A// B implements Comparable<A> <: Comparable<? super B>

OrderedSet // OK

interface Comparable<T extends Comparable<–T>> Scalaclass OrderedSet<T extends Comparable<T>>class A implements Comparable<A>OrderedSet<A> // OK

class B extends A// B implements Comparable<A> <: Comparable

OrderedSet // OK


A programmer hierarchy

language designera Pure Light ofprogramming

language or libraryimplementeran ingenious engineer

base programmeran obscure rower


Variance annotations

Use-site variance more general than definition-siteinstead of defining A<+T> once,use A<? extends T> everywhere!

* It’s unfair to impose to the base programmer the difficulties thatcould have been adressed by language designers or implementers

using classes, especially generics,is easier that defining themdefinition-site variance should be added to Javaand enlarged to all classes in C]

most of the burden of use-site variance would be avoided


Genericity (the end)

Ideal specificationsno type erasuremixed implementation à la C]

definition- and use-site variance (Scala)array invariancerecursive bound (F-bounded)no specialization of multiple generic instancesno static overloading on the formal typebetter support of the IDEs


Conclusions and propects

Plan



3 Genericity




Ideal specifications of OO languages

In static typingmetamodeling semantics of multiple inheritancegenerics with variance and runtime typeswithout overloading



Ideal specifications of OO languages

Why static typing?because

dynamic typing is unsafedynamic typing is too difficult for most programmersprogramming in dynamic typing is an art, not an industry

* static typing allows for exoskeletons like Eclipse

Before boarding an aircraft,be sure that all the avionics is statically typed!



a programmer dreams that he commands Eclipse,is it not Eclipse dreaming it is a programmer? (after 庄子)



Ideal specifications for other features

Constructors, i.e. initialization methodsan open problemno satisfying specification

Reflectionfirst-class metaclasses, based on variant genericsas an extension of Java Class class

language-level UML associations... and certainly a few other object-oriented features



What about existing languages?

Marginal evolution in Java and C]

global property conflicts (Java)covariant return types (C])definition-site variance (both)

Too many backwards incompatibilities* type erasure seems to be definitive (Java, Scala)

* a complete solution involves new languages



Just do it!the specifications are state-of-the-artsolutions exist for implementing it (another story...)



末尾


Classes and Types in an Ideal Object-Oriented …ducour/Publis/shenyang-classtype.pdf · Aristotle...

Documents

Transcript of Classes and Types in an Ideal Object-Oriented …ducour/Publis/shenyang-classtype.pdf · Aristotle...