Programming Languages

Transcription

1 Programming Languages Dr. Michael Petter WS 2016/17 Exercise Sheet 8 Assignment 8.1 Quiz 1. Can Smalltalk Inheritance be used to model Java s inheritance? What about attribute access? 2. In a Trait-based programming language, what purpose serves a concrete class, abstract class and a trait on its own? 3. Let C be a class, composed from the Mixins M and N. Suppose, M and N both implement a method f(). Is it true that The conflicting methods f() from M and N lead to a compiler error and have to be resolved manually There is no compiler error, but one implementation of f() from M or N overwrites the other 4. Now assume, that M and N are Traits instead of Mixins. Is it true that The conflicting methods f() from M and N lead to a compiler error and have to be resolved manually There is no compiler error, but one implementation of f() from M or N overwrites the other 5. Why is exclusion an important composition operator for Traits? 6. Consider the following C++ Code, trying to simulate a Mixin 1 template <class Super> 2 class Mixin : public Super { 3 public: virtual int m(){ 4 int result = Super::m(); 5 return result; 6 ; 7 ; the Super-reference in line 4 is resolved at compile time is resolved at runtime can not be resolved 1

2 7. Given the traits T 1, T 2 and class C: What is the value of (C T 1 )(a)? 1 T 1 = {a 1 T 2 = {a 2 C =, nil (T 1 + T 2 ) 8. (Attention: Several answers might be true for this question!) c 1 c 2 = c 1 c 2 is true for c 1 = {a = 0x1, c 2 = {b = 0x1 c 1 = mixin(c 3 )(c 2 ), c 2 = {a = 0x1, c 3 = {a = 0x2 c 1 = mixin(c 2 )(c 3 ), c 2 = {a = 0x1, c 3 = {a = 0x2 c 1 = mixin(c 3 )(c 4 ), c 2 = c 3 c 4, c 3 = {a = 0x1, c 4 = {a = 0x2 Solution Smalltalk inheritance is fine for Java. Redefinition of attributes is implemented as shadowing attributes, which is consistent with the smalltalk way of organizing inheritance. 2. A concrete class has neither conflicting method implementations nor undefined methods. Conceptually, it is the facility, where functionality from traits is assembled and mapped to the type hierarchy specified by interfaces. Whereas an abstract class may have conflicting method implementations or undefined methods. Finally, the difference between an abstract class and a trait is that a trait must not contain attributes, i.e., state. 3. b) 4. a) 5. Resolving conflicts is otherwise only possible via reimplementation of a method, leading to more redundant code. Consider the following Java 8 code as an example: interface A { default int f() { return 0; interface B { default int f() { return 1; class C implements A,B { public int f() { return A.super.f(); 2

3 Since Java 8 does not support exclusion, the method f in class C must be reimplemented. Assignment 8.2 Having fun with Mixins Reconsider the example from the lecture about synchronized file- and socket-streams. The following classes are given: F ilestream = {read = 0x1, write = 0x2 SocketStream = {read = 0x3, write = 0x4 SyncRW = {read = 0x5, write = 0x6 Your task is to come up with a new class SynchedF ilestream which mixes the class SyncRW into the class F ilestream. Solution 8.2 mixin(syncrw ) = λx.syncrw x = λx.{super x (SyncRW x) Now define the actual new class: SynchedF ilestream = mixin(syncrw ) F ilestream = {super F ilestream (SyncRW F ilestream) = {super F ilestream {read = 0x5, write = 0x6 = {super F ilestream, read = 0x5, write = 0x6 Assignment 8.3 Mixins Ruby Implement the Stream Wrapper scenario from the lecture based on Ruby Mixins Solution 8.3 class Stream def read puts 'reading' return 0 def write(t) puts "writing #{t" class FStream < Stream attr_accessor :fname def = 'myfile' 3

4 def read data = super puts "from #{@fname" return data def write(p) super(p) puts "to #{@fname" module SynchRW def acquirelock() puts "Lock acquired" def releaselock() puts "Lock released" def write(p) acquirelock super(p) releaselock def read acquirelock data=super releaselock return data class SynchedFStream < FStream include SynchRW s = SynchedFStream.new s.write('wichtige Daten ') s.read() 4

5 Assignment 8.4 Implementation differences: Traits vs. Mixins A next mainstream implementation of traits comes with the Java version 8. Implement a solution for the Stream Wrapper problem. You may use the following code: interface Stream { int read(); interface FileStream exts Stream { default int read() { /*... */ interface NetworkStream exts Stream { default int read() { /*... */ interface Synch { default void acquirelock() { /*... */ default void releaselock() { /*... */ Compare your solution to the one based on Mixins from the last exercise sheet. What are the differences? Which one is more flexible w.r.t. software engineering aspects? Solution 8.4 There are two solutions to come up with something like the Synch-Mixin: Either statically generate particular wrapper interfaces to forward statically to the right parent (as done in the SynchFileStream). class SynchFileStream implements FileStream, Synch { public int read() { acquirelock(); int read = FileStream.super.read(); releaselock(); return read; Or generate a dynamic wrapper interface which opens up a new abstract method, which has to be dispatched to the right dynamic predecessor (kind of imitated via the interfaces SynchWrapper and SynchNetworkStream ) interface SynchWrapper exts Synch { int readinherited(); default int read() { acquirelock(); 5

6 int read = readinherited(); releaselock(); return read; class SynchNetworkStream implements NetworkStream, SynchWrapper { public int readinherited() { return NetworkStream.super.read(); public int read() { return SynchWrapper.super.read(); If we compare these solutions via Traits with the solution based on Mixins from last time, we see that the overwriting of method read() has to be done explicitely, if we resort to Traits, where as with Mixins, we automatically overwrite. Mixins further offer the possibility to treat the parent class as of variable type, while in Java s Virtual Extension Methods, we cannot do so. Assignment 8.5 Virtual Extension Methods The following Java 8 code does not compile: abstract class A { public abstract void f(); interface K { default void g() { System.out.println("G"); ; interface I exts K { default void f() { System.out.println("I"); ; interface J exts K { default void f() { System.out.println("J"); ; public class C exts A implements I,J { 1. How many errors are in this code? Elaborate extensively on the causes! 2. Fix the code, while conserving the given inheritance relation, so that the whole program compiles! Solution There are two errors reported: First, there is no implementation found for method A.f in C. Second, C inherits two different extension methods, I.f() and J.f(), which have to be differenciated. 2. C has to implement its abstract method, and at the same time disambiguates the two extension methods: 6

7 public class C exts A implements I,J { public void f() { I.super.f(); ; Assignment 8.6 Bonus: Exploring Scala Traits Consider the following Scala code: trait Foo { def f = println("foo.f") trait Bar { def f = println("bar.f") trait Baz { def f = println("baz.f") 1. Is the call to the function f the same in FooBarBaz and FooBazBar? class FooBarBaz exts Foo with Bar with Baz { override def f = super.f class FooBazBar exts Foo with Baz with Bar { override def f = super.f 2. Would the example still compile if we change the trait Baz as in the following? trait Baz { def f = super.f Solution The function of the right-most trait is called! That means for FooBarBaz the function Baz.f is called and for FooBazBar the function Bar.f. 2. The example does not compile since super cannot be statically bound. 7