Jam: A Smooth Extension With Java Mixins

Transcription

1 Jam: A Smooth Extension With Java Mixins Davide Ancona, Giovanni Lagorio, Ellena Zucca Presentation created by

2 Left-out Jam abstract syntax Formal definitions of Jam static semantics Formal definitions of Jam dynamic semantics Proof of soundness of JAM type system (from the soundness of Java type system and theorem stating that translation preserves the static semantics)

3 Introduction Mixins = Parametric heir classes Class-to to-class functions (uniform extensions to many different parent classes) class H1 extends P1 {decs => mixin M {decs{ decs; class H1 = M extends P1 Mixins make possible to mix different ingredients during a creation of classes Mixins are not strictly related to OOP but can be considered as a mechanism for module composition a rigorous mathematic model can be created

4 Mixins Today Few Attempts to design real OOP languages that support Mixins LISP: : original, introduction of the term of Mixin ML: proposal of extending only Smalltalk: : a working extension (oopsla 96) Java: working, smooth, natural, cool

5 JAM: Basic facts Minimal extension of Java Upward compatible extension of Java 1.0 Type system of Java + a new kind of types: mixin types Dynamic semantics is directly defined by translation into Java JAM 2 Java translator is available at disi.unige.it/person/lagoriog/jam/ LALR grammer available as well

6 JAM: Introduction mixin Undo { inherited String gettext(); inherited void settext{string S; String lasttext; void settext(string s) { lasttext= gettext(); super.settext(s); void undo() { settext(lasttext) Components expected to be provided by a parent class Components defined in the mixin (can also override or hide inherited components) class TextBox extends Component { String text;... String gettext(){... ; void SetText(String S){... ; The methods must have the same argument and return types and equivalent throws clause as those in the mixin class TextBoxWithUndo = Undo extends TextBox{

7 JAM: Introduction II Expected semantics: copy principle: A class obtained instantiating a mixin M on a parent class P should have the same behavior as a usual heir of P whose body contains a copy of all the components defined in M The heir class obtained instantiating the mixin must be a correct Java heir class some constraints (described later)

8 Mixins as types class TextBoxWithUndo = Undo extends TextBox{ class BreakIteratorWithUndo = Undo extends java.text.breakiterator{ class TestUndo { void f() { g(new TextBoxWithUndo()); g(new BreakIteratorWithUndo()); void g(undo u) { u.settext( foo ); u.settext( bar ); System.out.println( Previous text: +u.lasttext); System.out.println( Current text: +u.gettext()); Mixin instance is a subtype of both the mixin and the parent class This approach brings the expressive power of multiple Inheritence without introducing its complication

9 Other components of a mixin declaration Mixins similarity to usual heir classes should provide all they features Interfaces: mixins can implement int. in the same way a class does Constructors: : cannot be declared in a mixin but only for each single mixin instance in the point of instantiation Inherited instance fields: : as usual: using this.id or super.id (when a defined field hides an inherited one) Static members: : are not considered part of a mixin type but every class that is a instance of M has its own copy of static components declared in the mixin

10 Constraints on instantiation Parent class P,, In addition to provision of implementation to the inherited parts in M,, can contain methods that interfere with those in M Illegal overriding/hiding: : if newly defined method in M has the same signature and different return type/kind (static/instance)/incompatible throws Unexpected overriding/hiding: : instantiating of a mixin to a parent class if both contain a method with the same signature, return type, kind, compatible throws it was not planned when declaring a mixin.. It is left legal in Jam (a warning is generated only). Ambiguous overloading: : e.g. Undo.undo( ) contains a call settext(null); Now, let s instantiate Undo on a class Boom that also defines settext(integer) the call settext(null) now becomes ambigous (null can be converted to any reference type (inc. String or Integer)

11 Overloading Java rules smoothly extends to Jam (including mixin types among other reference types) Every mixin instance is a subtype of (can be converted to) the corresponding mixin type Special care needed for handling conflicts between an inherited and a defined method in a mixin class A { class B extends A { class Parent { void f(b b) { class Heir { void f(a a) { mixin M { inherited void f(b b); void f(a a) { class Test { void test(heir h, B b, M m) { h.f(b); //AMBIGOUS m.f(b); //AMBIGUOUS? No, the inherited methods in a mixin are not annotated with type Mbut Parent(M) (generic parent) which is considered to be a supertype of M

12 Use of this in mixins Problem: What static type has this in a method declared in a mixin M? Independent type-checking of mixins M In a class H,, instance of M H class A { static int f(m m) {... static boolean f(h h) {... mixin M { void g() { int i= A.f(this); class H= M extends Object { class H { void g() { int i= A.f(this); //ERROR In a mixin definition in Jam, there is no way to refer to the parametric types of either the parent or the heir class resulting from instantiation solution: use of this as an argument in methods and constructor invocations inside a mixin is forbidden Non Equiv alent defini tions

13 Limitations It is not possible to refer either the generic parent class (to which the mixin will be applied) or the generic heir class obtained by instantiation Example: A class H, heir of P, cannot be abstracted into a mixin when it class P contains: { static int counter; (explicit) references to types H/P (except for most cases of accessing static members) class H extends P { invocations of H/P constructors static int counter; static void incrthat() {++P.counter; explicit... reference to P int value; public boolean equals(object that) { if(that instanceof H) return ((H)that).value == value; return false; H is unknown to the mixin

14 Jam to java translation I The idea of defining a Java extension and translating it to Java was taken from pizza (and its recent evolution GJ (Generic Java)) The behavior of a class H obtained by instantiating a mixin M on a parent P must be equivalent to that of a class obtained by extending P by all the defined components of M (copy principle) every inst. Of M a class extending P and declaring all components defined in M (+ possible constructors in the instantiation) Mixin names can be used as reference types (independently on mixin instance) and every class which is an instance of a mixin must be subtype of both mixin and the parent class must be mapped into a class or interface types Natural approach: Mixins interfaces; Mixin instances classes implementing the interfaces (besides extending parent). But it doesn t work: mixins can declare fields while interfaces cannot

15 Jam to java translation II The other approach: translating M to a class would require to simulate (in Java) the implicit Jam type conversion from the mixin instance to the mixin type too complicated The first approach was adopted via standard solution: simulating fields by pairs of accessor methods: For each field f in a mixin M declaration, the methods M_$get$_f and M_$set$_f are declared in the interface corresponding to the mixin declaration; then in every class that represents translation of a mixin instance, f is declared as a field and the methods are implemented in the obvious way Inherited fields: : translated exactly in the same way (pair of accessor functions) Static fields: : do not belong to the mixin type no accessor f. for the stat. fields in the interfaces

16 Jam to java translation: Mixin 2 interface example mixin Undo { inherited String gettext(); inherited void settext{string S; String lasttext; void settext(string s) { lasttext= gettext(); super.settext(s); void undo() { settext(lasttext) interface Parent$Undo { String gettext(); void settext(string s); interface Undo extends Parent$Undo { String Undo_$get$_lastText(); String Undo_$set$_lastText(String new value); void settext(string s); void undo(); The mixin must be split into two interfaces because the first one represents the Parent(Undo) type, I.e. the generic parent type on which the mixin can be instantiated and is necessary to correctly simulate the Jam extended rule for overloading resolution (the inherited atributes considered less specific)

17 Jam to java translation: Mixin instance 2 class example class Example { String donald= duck ; String gettext() {return donald; void SetText(String donald) { this.donald= donald; class ExampleWithUndo = Undo extends Example{ Inside a mixin, no accessor f. are needed Accessor methods invocation Is only needed when the field Access is on an expression of The mixin type (IN THE CASE OF MIXIN INSTANCE, THE CODE REMAINS UNCHANCHED) class Example {... //UNMODIFIED class ExampleWithUndo extends Example implements Undo { String lasttext; String Undo_$get$_lastText() { return lasttext String Undo_$set$_lastText (String newvalue) { return lasttext= newvalue void settext(string s) { lasttext=gettext(); super.settext(s); void undo() { settext(lasttext);

18 Implementation There are two approaches (terminology introduced by Pizza creators - more: more: Odersky, Wadler. Pizza Into Java: Translating Theory Into Practice; ACM Symp.. On P.o.P.L., Jan 1997): Heterogeneous translation: : copy principle, favors the running time of code over the byte-code size Homogeneous translation: : shares code at the cost of some overhead due to casts To obtain byte-code, the translator called jamc and a java compiler are required Jamc performs complete lexical and syntactic analysis but a partial type-checking only these errors should be found by Java compiler Jamc has to deal with two more features: packages and access modifiers (for details see the extended text).

19 Comparision Smalltalk with mixins: : upward compatible extension, similar to Jam since Smalltalk is an untyped language a lot of problems do not exist especially mixins can be eliminated by creating a class for each mixin invocation, while in Jam mixins are types they cannot be simply eliminated In Smalltalk, Mixin can be composed with others (it behaves exactly like the function composition) and extracted from a class MixedJava theoretical language with Java-like syntax defining mixins and interfaces only; usual classes are seen as particular mixins which define all the components Atomix mixins (similar to a class) Compound mixins (roughly based on function composition) Inherited component can be methods only ( interfaces) Ad-hoc solution for unexpected overriding (Jam: methods in the parent class are uniformly overridden by methods in the heir) solution based on keeping both brings ambiguities like in the case of multiple inheritance For more see: Flatt, ; Classes and Mixins; ACM Symp.. On P.o.P.L., Jan 1998):

20 Further work Mixins vs. Parametric types: : (Pizza,( GJ, PolyJ): solve the main disadvantage of mixins: : inability to refer to either the generic parent class to which the mixins will be applied or to the generic heir class obtained by instantiation; but it s rather orthogonal approach Flexible matching: contravariance on argument type and covariance on return (and invariance on exception types) in the case of inherited methods Shared static components: each class has its own copy of the static components declared in a mixin; ; the second possibility is to share a unique copy (they would be part of the mixin type) and the third one is to leave to the user (e.g. via shared static) ) to decide); The shared approach would require to introduce some constraints (e.g. shared static method may not invoke the static one)