Java 5. Lecture 33: Java 5. Generics Finally Added. Constrained Genericity

Transcription

1 Java 5 Lecture 33: Java 5 CSC 131 Fall, 2014 Kim Bruce Generics Enhanced for loop (w/iterators) Auto-boxing and unboxing of primitive types Type-safe enumerated types Static Import Simpler I/O Now on Java 8 Generics Finally Added Templates done well (unlike C++) - Type parameters to classes and methods. - Type-checked at compile time. - Allows clearer code and earlier detection of errors. - Biggest impact on Collection classes. Limitations - Virtual machine has not changed. - Translated into old code with casts - Casts and instanceof don't work correctly - Can t construct arrays involving variable type. Constrained Genericity Introduced by Cardelli & Wegner 1985 Quickly added to Eiffel Need to constrain type parameters class List<T extends GraphicObject> { private T head; head.show() head.move(dx,dy)... Guarantees presence of methods from GraphicObject in objects of type T.

2 Constrained Genericity Constraining Genericity Recall the way we constrained type params in Clu: sorted_bag = cluster [t : type] is create, insert,... where t has lt, equal : proctype (t,t) returns (bool); How can we model this in Java 5? interface Comparable { boolean equal(comparable other); boolean lessthan(comparable other); class BST<T extends Comparable> {... class OrderedRecord implements Comparable {... // inst vble declarations boolean lessthan(comparable other) {??? F-Bounded Quantification Mitchell et al introduced F-bounded quantification interface Comparable<T> { boolean equal(t other); boolean lessthan(t other); class BST<T extends Comparable<T>> {... class OrderedRecord implements Comparable<OrderedRecord> { boolean lessthan(orderedrecord other) { if (...)... F-Bounded Problems Seems to solve the problem, but sometimes too complex to write easily. public class ComparableAssoc <Key extends Comparable<Key>, Value> implements Comparable<ComparableAssoc<Key,Value>> { Not preserved by subclasses. - Suppose C extends Comparable<C> and D extends C - Then D extends Comparable<C> but not Comparable<D> See Bruce, Some Challenging Typing Issues in Object- Oriented Languages on my web pages under recent papers.

3 Also Polymorphic Methods Java Wild Cards interface Visitor<T> { T visitnumber(int n); T visitsum(t left, T right); abstract class Expr { public <T> T accept(visitor<t> v); class Number extends Expr { private int n; public Number(int n) { this.n = n; public <T> T accept(visitor<t> v) { return v.visitnumber(this.n); Four ways to specify type parameters : T : fixed type? extends T : some extension of T,? super T : some type that T extends,? : any type Examples: C? extends T : can be C<U> for any U extending T. C? super T : can be C<U> for any U s.t. T extends U. C<?>: can be C<U> for any U. Example What do wildcards mean? In class TreeSet<E>: - boolean addall( Collection<? extends E> c ) - constructor: TreeSet( Comparator<? super E> c ) - Comparator <? super E> comparator( ) - where interface Comparator<T> has method int compare( T o1, T o2 ) In libraries almost all occurrences are of form? extends E or just?, and are in parameter position. C<? extends T> (t<:t). C<t> C<? super T> (t:>t). C<t> C<?> t. C<t> Compare with C<t extends T> (t<:t). C<t>

4 Wildcard Restricts Usage If ds : List<? extends T> t extends T.List<t> then can access elements, but not insert. More carefully, if List<T> has methods get: () T, set: T void then ds.get() will return value of type T, but ds.set(o) always illegal, no matter what type of o. I.e., ds is read-only Covariant occurrences of T are OK, contravariant are not Restrictions Confusing?s are not equal to each other or even itself: public void twiddle(stack<?> s) {" if (s.empty())" s.push(s.pop());" Illegal, because type of s.pop() not recognized as same as argument type of s.push(...). Can t even write swap Can fix by calling polymorphic method where type given a name. Avoiding Wildcards Are Wild-Cards Worth It? Recall from logic, if B does not contain t then t.(a(t) B) ( t.a(t)) B Thus by Curry-Howard equivalence <T extends C> void m(list<t> alist){... is equivalent to void m(list<? extends C> alist){... However, there is no equivalent for return type or types of fields. They show up in all of the Collection classes: public ArrayList( Collection<? extends E> c )" public void addall( Collection<? extends E> c )" public void removeall( Collection<?> c ) " " Can be replaced by similar: public ArrayList<T extends E>( Collection<T> c )" public <T extends E> void addall( Collection<T> c )" public <T> void removeall( Collection<T> c )" Provides more information: Can write swap

5 Eiffel Features Introduced in 1985 by Bertrand Meyer Design goals: - Promote clear and elegant programming. - Support object-oriented design, including design-bycontract Design-by-contract is most important impact Purely object-oriented Multiple inheritance Automatic memory management Assertions integral part of language Static typing (but not type-safe, alas) Design by Contract Treat method calls as contractual obligations - Client must ensure that preconditions of the method are met when sending a message. - If client meets the preconditions then the routine guarantees that the postconditions will hold on exit. - Both parties may also guarantee that certain properties (the class invariant) hold on entrance to methods and again on exit. Class Definition class" HELLO_WORLD" create" make" feature" make" do" print ("Hello, world%n")" end -- other method defs" invariant -- class invariant" end

6 Method Definition connect_to_server (server: SOCKET) -- Connect to a server or give up after 10 attempts. require server /= Void and then server.address /= Void local attempts: INTEGER do server.connect ensure connected: server.is_connected rescue if attempts < 10 then attempts := attempts + 1 retry end end Inheritance & Assertions What changes can you make in preconditions and postconditions of method when override? Need to maintain contract as masquerades. Can - weaken preconditions - strengthen postconditions Static Typing Issues In Eiffel subclass, can - specialize type of instance variables - specialize return type of methods - specialize parameter type of methods First & third lead to errors Several proposals made to fix, including wholeprogram analysis - None appear to have been implemented like Current class LINKABLE [G]" feature" item: G; " right: like Current; " putright (other: like Current) is" do" right := other" ensure" chained: right = other" end;" end -- class LINKABLE Type like Current is type of class

7 class BILINKABLE [G] inherit LINKABLE [G]" redefine" putright" end" " feature " left: like Current; -- Left neighbor" putright (other: like Current) is" -- Put `other' to right of current cell." do" right := other;" if (other /= Void) then" other.simpleputleft (Current)" end" end;" putleft (other: like Current) is..." Define Very Flexible - class LINKEDLIST[NODE -> LINKABLE]... - Can instantiate with LINKABLE to get singly-linked list or BILINKABLE to get doubly-linked list. Can t do in Java or C++ - Why? Type Unsafe - See next week s homework implicit change of parameter type - Subclass, but not subtype like Java extends LOOJ Binary Methods Extension of Java to support like Current in type-safe way. - Replace like Current by ThisClass Type system modeled on our earlier language, LOOM A binary method is one with a parameter that is the same type as the receiver. Tricky to write with inheritance: -class C {void m (C c) {... -class D extends C {void m (D d) {... Results in overloading, not overriding in D

8 ThisClass Example: Linked List With ThisClass, not hard: -class C {void m (ThisClass c) {... -class D extends C { void m (ThisClass d) {... Now: method is binary iff has a parameter of type ThisClass Useful in other contexts as well: -ThisClass clone() {... class Node<T> { " ThisClass next; " Node(ThisClass next) {... " ThisClass getnext() {" return next;" public void setnext(thisclass next){" this.next = next;..." Using Factory classes, can get This constructor Example: Linked List LOOJ: Constrained Genericity class DblNode<T> extends Node<T>{ " ThisClass prev; " Node(ThisClass next, ThisClass prev) {... " ThisClass getprev() {" return prev;" public void setnext(thisclass next) {" super.setnext(next); " if (next = null) {next.setprev(this);..." Can create linked lists like Eiffel abstract class Comparable {" boolean equal(thisclass other);" boolean lessthan(thisclass other);" class BST<T extends Comparable> {... class OrderedRecord extends Comparable {"... // inst vble declarations" boolean lessthan(thisclass other) {"..."

9 Versus: F-Bounded Problems with ThisClass interface Comparable<T> {" boolean equal(t other);" boolean lessthan(t other);" class BST<T extends Comparable<T>> {... class OrderedRecord " implements Comparable<OrderedRecord> {" boolean lessthan(orderedrecord other) {" if (...)..." public void breakit(node<t> n1, Node<T> n2){" n1.setnext(n2);"... " Node<T> n; " DblNode<T> dn; " breakit(dn, n); dn.setnext(n) // error Calls setnext on a DblNode<T> with an argument of type Node<T>, a type error Exact Types Node with Exact Types To avoid type problems, introduce exact types An expression with static always refers to an object with run-time type T (and not an extension of T). c Exact types can masquerade as non-exact <: T class Node<T> { next; " Node(@ThisClass next) {... getnext() {" return next;" public void setnext(@thisclass next) {" this.next = next;..."

10 Type-Checking Classes When type checking a class with declaration: class C extends D we assume: - C extends D (as always) - ThisClass extends C - Restrict binary method invocations to receivers whose type is known exactly. - Non-binary methods are typed as in Java. Type-checking Methods Recall binary method - void" Substitute receiver type for ThisClass in signature when invoking Node<T> exactdblenode" node.setnext exactnode.setnext // error" void" exactdblnode.setnext void Type-checking Methods Type Safety Recall getnext - getnext: ( Node<T> exactdblenode" node.getnext() : Node lose exactness Provide format type-checking rules & semantics Prove LOOJ core is type safety. - Complications with using ThisClass in interfaces - Also introduced ThisType or ThisInterface exactnode.getnext() exactdblnode.getnext()

11 LOOJ implementation F-bounded vs "ThisClass" Both solve binary method problem Extended Java compiler generates JVML However keep instance variables for type parameters in JVML - LOOJ supports type casts and instanceof for type variables F-bounded: - Not preserved under subclass. - Encoding requires extra type parameter in interface ThisClass: - Preserved under subclass - Must distinguish exact vs. regular types. - Can't send binary message to #-type. - If no occurrences of MyType then get exactly same effect as in Java.