all FREECO11-workshop-papers.pdf - trese

7 targetType = this.parentType;8 }9 // virtualBinding is applicable only if the default binding fails10 constraint bottomUpResolution = skip(defaultBinding, virtualBinding);11 // initialize the instance variables and activate binding.12 method subclassOf(childType, parentType) {...}13 }Each instance of MethodInheritance defines an inheritance relationbetween the childType and parentType. The virtualBindingin this example selects all calls to the childType and reroutesthese to the parentType, effectively specifying virtual methodlookup. This virtual lookup only takes place if regular lookupfails, specified by the constraint bottomUpResolution: If the defaultbinding succeeds, the virtualBinding is skipped.5. DEFINING INHERITANCE OF FIELDSDefining the availability and accessibility of fields from superclassesis needed for expressing various inheritance- (andother composition-) semantics. Our previous version of theCo-op language, Co-op/I, did not support this; this paperexplains the application of controlling field composition semanticsfor the first time.For example, the Smalltalk style inheritance we have definedearlier, also creates FieldInheritance. Even though thefields of a Person are not directly accessible from its subclassStudent, they are still addressable through methods definedin the class Person. Thus, upon creation of a child class, alsoall fields in its superclasses must be created. That is whatthe composition operator FieldInheritance does.FieldInheritance also creates a relation between an instanceof the child class, and an instance of its superclass 1 . ForSmalltalk style inheritance, this relation is created using theLocalFieldAccess operator, which allows private field access only.Now, consider you do not want field access to be limitedto the declaring class only, but you want them to be alsoaddressable through the child classes. For example, allowingus to write the following implementation of Student:1 class Student {2 method study() {3 return ”Is that necessary for ” + this.title + ” ” + this.name + ”?”;4 }5 }The field accesses in the method study() address fields definedin the super class, just like the way we can address methodsdefined in the super class. Therefore, defining a bindingwhich realizes accessing fields through child classes can bedone in a similar way to defining it for methods:1 class InheritedFieldAccess {2 var child;3 var parent;4 // Binding for field lookup in parent type5 binding inheritFields = (messageKind == ”Lookup”6 &target==this.child){7 target = this.parent;8 targetType = System.classOf(this.parent);9 this = this.parent;10 }11 // inheritFields is applicable only if the default binding fails12 constraint bottomUpResolution = skip(defaultBinding, inheritFields);13 // initialize instance and activate binding14 method initDispatch(child, parent) { ... }15 }The most notable difference with MethodInheritance is that inthis case we have a parent and child instance instead of type,1 This does not involve specific and optimized memory layoutsfor objectsbecause field values are instance properties, whereas methodbehavior is a property of the type.Now, we can use field inheritance as shown in the examplebelow. First, we create a relation between the parent andchild type and then we can access all fields of the parenttype also through any instance of a child type, which themethod study() does.1 MethodInheritance.subclassOf(Student, Person);2 FieldInheritance.subclassOf(Student, Person, InheritedFieldAccess);3 var alice = Student.new(”Alice”, ”Bachelor”);4 System.println( alice.study() );Languages like Java and C++, which enable inheritanceof fields, also provide mechanisms to let the developer selectfields which are not accessible through subtypes. We havemodeled this using the SelectiveFieldInheritance composition operator,which can replace the InheritedFieldInheritance. This operatoronly enables inheritance for fields that are selectedexplicitly. Its use is as follows:1 MethodInheritance.subclassOf(Student, Person);2 var selectiveInh = SelectiveFieldInheritance.new();3 selectiveInh.initDispatch(Student, Person);4 selectiveInh.addField(”name”);5 var alice = Student.new(”Alice”, ”Bachelor”);6 System.println( alice.study() );Since this example allows subclasses of Person only accessto the field name, the implementation of Student shown in thebeginning of this section will yield a runtime error. However,the following implementation of Student is correct when thisselective inheritance is applied:1 class Student {2 method study() {3 return ”Is that necessary for ” + this.name + ”?”;4 }5 }Traditional programming languages allow programmers toadd access rules to fields or methods by adding a modifierto their declaration. To enable a similar programming style,Co-op allows the addition of annotations to field and methoddeclarations. Using reflective capabilities to access theseannotations—which are not yet possible in the Co-op/IIprototype—allows implementing the FieldInheritance compositionoperator in such a way that it, for example, only appliesto fields with the @Inherited annotation:1 class Person {2 var @Inherited name;3 var title;4 }6. FREEING FIELD ACCESS BEHAVIOR FROMKEYWORDSIn most (OO) programming languages, there are manykeywords and fixed language constructs to manipulate theway that data is, or can be, accessed. We mention a fewexamples:• Access modifiers in Java, C++ and C# are public, protected,and private. A language like C++ adds a friendkeyword to express yet another form of access rightson data (as well as behavior). Note that there is a widerange of possible access modifiers, when including thenotion of package-level protection, or the distinctionbetween class-level vs instance-level protection.• The Java, C++ or C# keyword static controls whetherall instances of a class share a field, or each has its owncopy.