'&$%CSE 341:Programming LanguagesDan GrossmanFall 2004Lecture 25— Named Types; Class vs. Types; InterfacesDan Grossman CSE341 Fall 2004, Lecture 25 1'&$%Named TypesIn Java/C++/C#/..., types don’t look like [t10 m1:(t11,...),..., tn0 mn(tn1,...)].Instead they look like C where C is a class or interface.But everything we just learned about subtyping still applies!Yet the only subtyping is (the transitive closure of) declared subtypes(e.g., class C extends D implements I,J).Given types D, I, and J, ensure objects produced by class C’sconstructors can have subtypes (more methods, contra/co, etc.)Dan Grossman CSE341 Fall 2004, Lecture 25 2'&$%Named vs. UnnamedFor preventing “message not understood”, unnamed (“structural”)types worked fine.But many languages have named (“nominal”) types.Which is better is a tired old argument, but fortunately it has someinteresting intellectual points (unlike emacs vs. vi).First, frame the question more narrowly: Should subtyping be nominalor structural? (Named types don’t preclude structural subtyping, e.g.casting between two otherwise-unrelated interfaces.)Dan Grossman CSE341 Fall 2004, Lecture 25 3'&$%Some Fair PointsFor structural subtyping:• Allows more code reuse, while remaining sound.• Does not require refactoring or adding “implements clauses”later when you discover you could share some implementation.• A simpler system (type names are just an abbreviation andconvenient way to write recursive types)For nominal subtyping:• Reject more code, which catches bugs and treating unmeaningfulmethod-name clashes as significant.• Confusion with classes saves keystrokes and “doing everythingtwice”?• Fewer subtypes makes type-checking (??) and efficientcode-generation easier.Dan Grossman CSE341 Fall 2004, Lecture 25 4'&$%The Grand ConfusionFor convenience, many languages confuse classes and types:• C is a class and a type• If C extends D, then:– instances of the class C inherit from the class D– expressions of type C can be subsumed to have type DDo you usually want this confusion? Probably.Do you always want “subclass implies subtype”?• No: Recall distTo for Point and 3DPoint.Do you always want “subtype implies subclass”?• No: Two classes with display methods may no inheritancerelationship.Dan Grossman CSE341 Fall 2004, Lecture 25 5'&$%Untangling Classes and Types• Classes define object behavior; subclassing inherits behavior• Subtyping defines substitutability• You often want subclasses to be subtypes; most languages giveyou no choice.Now some other common features make more sense:• “Abstract” methods:– Expand the supertype without providing behavior to subclass– Superclass does not implement behavior, so no constructorsallowed (an additional static check because the class isabstract)– The static-check is the only fundamental justification (trivial toprovide a method that raises an exception).• Interfaces...Dan Grossman CSE341 Fall 2004, Lecture 25 6'&$%InterfacesA Java interface is just a (named) object type.By implementing an interface, you get subsumption but no behavior.• Same thing with “multiple inheritance” when n − 1 superclasseshave all abstract methods. Should be called “multiplesubsumance”, but subsumance is not a word. :)• None of the semantic issues we previously discussed with multipleinheritance arise with interfaces.• But there are issues we didn’t discuss before because they’reabout typing, and we’ll skip now:– Lack of least supertypes– Ambiguity if “subsumption is not a run-time no-op” (coercive)Dan Grossman CSE341 Fall 2004, Lecture 25
View Full Document
Unlocking...