Lecture Questions. Types (binary expressions, etc). Refactoring, abstraction, better engineering. Testing. Error message generation/suppression.

Transcription

1 . p.1/39 Today 1. Specific questions and discussion from lecture. 2. Types: overloading, subtypes, and coercion. 3. Testing: structure and stress. 4. Objects: when, how, and why? 5. Top-down vs. bottom-up development. As always, please feel free to interrupt at any time, and I will try to answer or evade your question. If the answer sucks, tell me how and I ll try to fix it.

2 . p.2/39 Lecture Questions Types (binary expressions, etc). Refactoring, abstraction, better engineering. Testing. Error message generation/suppression.

3 . p.3/39 Types: Polymorphism I m a million different people from one day to the next... Examples of polymorphism you have seen: vs. 3e exprsto.isvar() vs. varsto.isvar(). Questions: How are these similar? How are they different?

4 . p.4/39 Subtyping One slot in many classes. Requires participating objects to have the same type. What types matter? Is this static or dynamic?

5 . p.5/39 Overloading One name for many actions. What restrictions? What types? Static or dynamic? Why not always use overloading?

6 . p.6/39 Example: a + b What is its type in the spec? What about non-numeric arguments? What kind of polymorphism? Why?

7 . p.7/39 For future reference How is typechecking a + b like typechecking f(a, b)? How is f(a,b) like typechecking g(a, b, c)? How can we adapt BinaryExpr.compatible(a, op, b) to handle f and g?

8 . p.8/39 Badness... STO checkfunction(sto op, STO [] args) { if (args.length == 2) return op.type().compatible(args[0], args[1]); else if (args.length == 3) return op.type().compatible(args[0], ags[1], args[2]); //... class Binary { Type left, right, result; STO compatible(sto a, STO b) { if (!compatible(a.type(), left)!compatible(b.type(), right)) return new ErrorSTO(); return new ExprSTO(result); ;

9 . p.9/39 Badness... class Ternary { Type ta, tb, tc, result; STO compatible(sto a, STO b) { if (!compatible(a.type(), ta)!compatible(b.type(), tb)!compatible(c.type(), tc)) return new ErrorSTO(); return new ExprSTO(result); ; //...

10 . p.10/39 Goodness! STO checkfunction(sto op, STO [] args) { return op.type().compatible(args); class FunctionSTO { Type [] params; Type result; STO compatible(sto [] args) { if (args.length!= params.length) return new ErrorSTO(); for (int i = 0; i < args.length; i++) { if (!compatible(args[i], params[i])) return new ErrorSTO(); return new ExprSTO(result); ;

11 . p.11/39 Example 2: a?b:c What is its type? First operand? Second and third? Results? Is this subtyping? Overloading? Something else? How would you type-check this?

12 . p.12/39 Typechecking a? b : c STO checkternary(sto a, STO b, STO c) { Type parent = commontype(b.type(), c.type()); if (a.isboolean() &&!parent.iserrortype()) return new ExprSTO(parent); return new ErrorSTO(); bool commontype(type a, Type b) { if (a.equals(b)) return a; Type p = commontype(a.parent(), b); if (!p.iserrortype()) return p; return commontype(a, b.parent());

13 . p.13/39 Coercion With the use of sufficient force, all problems become tractable. We saw there are only two + operators: +: (int, int ) = int +: (real, real) = real But thanks to coercion, + can be applied to all combinations of int and real. How does coercion work in this case? How is this related to subtyping?

14 . p.14/39 Coercion: example Types: (int, real) Does +: (int, int) apply? Is real a subtype of int? No. Does +: (real, real) apply? Is int (left) a subtype of real? Yes. = promote LHS to real = addreal(toreal(3), 4.2)

15 . p.15/39 Typechecking finit Polymorphism Subtype Parametric Overloading Coercion Relation to subtyping Implicit coercion in Oberon Questions?

16 . p.16/39 Testing Goals Achieve complete coverage (more later...). Minimize number of tests. Strategies Structure-based testing. Stress or nuclear testing.

17 . p.17/39 Structured testing Problem structure Doing type checking. So values don t matter only cover all types. Input structure Grammar rules are independent. So each can be tested in isolation. Problem structure 2 Many operators have the same type signatures. So you only need to test one.

18 . p.18/39 Structured testing I lied.

19 . p.19/39 Structured testing I lied. How? Variables types create dependencies (via symbol table). Your program may create more. Note: cleaner design = orthogonal implementation = fewer cases to test = fewer tests.

20 . p.20/39 Many different structures Syntactic structure. Program control structure (of your program). Program control structure (of Oberon program). Test edge cases like empty repetitions. Zero-one-many. Input structure. Test stateful aspects of the language (e.g. declaration order). Where is the state in your compiler? What accesses it? Spec structure.

21 . p.21/39 Testing: example ForStatement ::= T_FOR T_ID:ix T_ASSIGN Expr:start T_TO Expr:end OptBy:incr T_DO StatementList T_END ; OptBy ::= T_BY ConstExpr /* empty */ ; How many grammar branches? How many combinations of types? How many test cases?

22 . p.22/39 Testing: example 2 Operators +-* all have the following type: left right result int int int numeric numeric real * * error Only 6 test cases to cover all 3 operands, right? int + int int + real, real + int, real + real real + other, other + real

23 . p.23/39 Testing: example 2 But what if your code looks like this: Type compatible(type a, OpType op, Type b) { if (op.equals(optype.add_op)) { // do checks else { // XXX: DO THIS LATER Code structure matters! least once. Check every operator at

24 . p.24/39 Example: Spec structure The types of ix, start, end, and incr must be equivalent to INTEGER. Additionally, ix must be a variable. What needs to be tested? How many tests?

25 . p.25/39 Example: Spec structure The types of ix, start, end, and incr must be equivalent to INTEGER. Additionally, ix must be a variable. What needs to be tested? How many tests? Type of (each of) ix, start, end, incr. ix is a variable

26 . p.26/39 Nuclear testing With a big enougn bomb, you re bound to hit something... Even the most careful structured testing will miss some cases. As a last resort, testing with large, complex (real-world) programs can sometimes find more bugs. This is both inefficient and incomplete, but can be useful.

27 . p.27/39 Testing, concluded Kinds of structure Problem Syntax Control flow Specification Importance of boundary cases The nuclear option Questions?

28 . p.28/39 Objects: why? Why private members? Information hiding. But why? Localization and control of state access. Examples? Why not global (static) state? Parallelism, cleanliness.

29 . p.29/39 Objects: what? Here are some techniques we ve talked about in class. data hiding subtyping delegation singletons All of them hurt, each in its own way. What do they do? What are they for?

30 . p.30/39 Data hiding: what? It s like exercise: it hurts now, but you ll thank yourself for it later. Defends against temptation of bad design. Makes it easier to change your mind later. Localizes state-changing code Who clobbered my member? Centralizes control of state update (e.g. error checking).

31 . p.31/39 Subtyping: what? It s like organizing your notes in file folders: tedious now, but when you have 100+ pages from each class, you ll be glad you did it. Common interface (Java interfaces). Allows many unrelated implementations of the same interface, e.g. lists as linked lists, arrays, trees, etc. Shared implementation (Java classes). Provides a common interface to related implementations, and also promotes controlled code reuse.

32 . p.32/39 Delegation: what? It s like giving your partner some parts of the project: it s hard to watch him insistently doing it wrong, but you wouldn t have time to do it right yourself. Forward messages to an object better-equipped to deal with them. Allow shared functionality orthogonal to subtypes. e.g. STO and TypeSTO. With inheritance? With delegation? Which do you prefer? Related: visitor pattern.

33 . p.33/39 Singleton: what? It may take some decapitation, but in the end there can be only one. Like global variables. How? How can it be implemented using class things? Static objects. Static methods. Why might calling a single static object s methods be better? How can we combine the two?

34 . p.34/39 Objects: when? Often you will only know that you should use one of these techniques after writing a piece of ugly code. Then it s time to refactor. Here are some patterns you may recognize: case statements and long if/else sequences. Repeated identical code. Repeated code with slight variations. Complex methods.

35 . p.35/39 case int f(type x) { if (x.isint()) return f1(x); else if (x.isreal()) return f2(x); //... int other_f(type x) { // same if/else as above class Type { int f() { /* ERROR */ ; class Int extends Type { int f() { /* body of f1(x) */ ; class Int extends Type { int f() { /* body of f2(x) */ ; int f(type x) { return x.f()

36 . p.36/39 Repeated calls bool checka() { checkchildren(); if (isbinary()) checkcompatible(); return sawerror(); bool checkb() { checkchildren(); if (isbinary()) checkcompatible(); checkconstant(); return sawerror(); class AorB { bool check() { checkchildren(); if (isbinary()) checkcompatible(); return sawerror(); ; class B extends AorB { bool stuff() { return (super.check() && isconstant());

37 . p.37/39 Repeated similar calls bool checka() { if (!issimple(left)!isconstant(right)) reporterror(); bool checkb() { if (!isint(left)!isreal(right)) reporterror(); class AorB { bool leftcheck() { return issimple(left); bool rightcheck() { return isconstant(right); bool check() { if (!leftcheck()!rightcheck()) reporterror(); ; class B extends AorB { bool leftcheck() { return isint(left); bool rightcheck() { return isreal(right);

38 . p.38/39 Complex methods private OpType myop; void gencode() { // type checking if ((left.isint() && right.isint()) (left.isbool() && right.isarray())) /* okay */; else reporterror(); // code gen void gencode() { if (!myop.compatible(left, right)) reporterror(); // code gen. class OpType { bool compatible(sto a, STO b) { return ((a.isint() && b.isint()) (a.isbool() && b.isarray()));

39 . p.39/39 Objects: review Warning signs case statements duplicate code structure too many things done in one place Techniques data hiding subtyping (interface vs. implementation) delegation