selective open recursion modular reasoning about components and inheritance l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Selective Open Recursion Modular Reasoning about Components and Inheritance PowerPoint Presentation
Download Presentation
Selective Open Recursion Modular Reasoning about Components and Inheritance

Loading in 2 Seconds...

play fullscreen
1 / 42

Selective Open Recursion Modular Reasoning about Components and Inheritance - PowerPoint PPT Presentation


  • 257 Views
  • Uploaded on

Selective Open Recursion Modular Reasoning about Components and Inheritance. Jonathan Aldrich Carnegie Mellon University Kevin Donnelly Boston University. Outline. The Fragile Base Class Problem Selective Open Recursion Implementation & Analysis

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Selective Open Recursion Modular Reasoning about Components and Inheritance' - Jims


Download Now An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
selective open recursion modular reasoning about components and inheritance

Selective Open RecursionModular Reasoning aboutComponents and Inheritance

Jonathan Aldrich Carnegie Mellon University

Kevin Donnelly Boston University

outline
Outline
  • The Fragile Base Class Problem
  • Selective Open Recursion
  • Implementation & Analysis
  • Discussion
inheritance and information hiding
Inheritance and Information Hiding
  • Parnas’ advice:
    • Modularize a system to hide information that may change
inheritance and information hiding4
Inheritance and Information Hiding
  • Parnas’ advice:
    • Modularize a system to hide information that may change
  • Research question
    • How to hide information in component-based systems with inheritance?
a challenge open recursion
A Challenge: Open Recursion
  • Recursion
    • Objects can make self-calls to their own methods
a challenge open recursion6
A Challenge: Open Recursion
  • Recursion
    • Objects can make self-calls to their own methods
  • Open Recursion
    • Self-calls are dynamically dispatched
      • I.e., target of call is “open” and can be overridden
    • Beneficial in “template method” design patterns
open recursion
class Window {

void draw() {

// draw background

this.drawForeground();

}

void drawForeground() { … }

}

class MyWindow {

void draw() { super.draw(); }

void drawForeground() {

super.drawForeground();

...

}

...

}

Open Recursion

Window

draw

drawFore

open recursion8
class Window {

void draw() {

// draw background

this.drawForeground();

}

void drawForeground() { … }

}

class MyWindow {

void draw() { super.draw(); }

void drawForeground() {

super.drawForeground();

...

}

...

}

Open Recursion

Window

draw

drawFore

Window

MyWindow

draw

draw

drawFore

drawFore

hook methods
Hook Methods
  • Hook methods
    • Called by this when some event occurs
    • Intended as extension point for subclasses
    • Open recursion is necessary
hook methods10
Hook Methods
  • Hook methods
    • Called by this when some event occurs
    • Intended as extension point for subclasses
    • Open recursion is necessary
  • Other methods
    • Perform some task
    • May be overridden, but has no “event” semantics
    • Open recursion unnecessary
      • At best, minor convenience
      • Has potential to cause the Fragile Base Class Problem
the fragile base class problem
class CountingSet extends Set {

private int count;

void add(Object elem) {

super.add(elem);

count++;

}

void addAll(Collection c){

super.addAll(c);

count+=c.size();

}

int size() { return count; }

// other functions

}

The Fragile Base Class Problem

Set

CountingSet

addAll

addAll

add

add

the fragile base class problem12
class CountingSet extends Set {

private int count;

void add(Object elem) {

super.add(elem);

count++;

}

void addAll(Collection c){

super.addAll(c);

count+=c.size();

}

int size() { return count; }

// other functions

}

The Fragile Base Class Problem

Set

CountingSet

addAll

addAll

add

add

Implicit assumption:

Set.addAll does not call Set.add

If this assumption is violated

(or changed), CountingSet breaks

the fragile base class problem13
The Fragile Base Class Problem
  • Definition (for this instance of FBC)
    • A class may depend on the calling patterns of a superclass, and break if these are changed
two solutions to the fbc
Two Solutions to the FBC
  • Document open recursion

[Kiczales & Lamping, Steyaert et al., Ruby & Leavens]

    • Exposes information, rather than hiding it
    • Prohibits natural changes to superclass

Use forwarding to avoid open recursion

[Bloch,Szyperski]

Gives up benefits of open recursion

Can we get the benefits of open recursion without the reasoning costs?

two solutions to the fbc15
Two Solutions to the FBC
  • Document open recursion

[Kiczales & Lamping, Steyaert et al., Ruby & Leavens]

    • Exposes information, rather than hiding it
    • Prohibits natural changes to superclass
  • Use forwarding to avoid open recursion

[Bloch,Szyperski]

    • Gives up benefits of open recursion

Can we get the benefits of open recursion without the reasoning costs?

two solutions to the fbc16
Two Solutions to the FBC
  • Document open recursion

[Kiczales & Lamping, Steyaert et al., Ruby & Leavens]

    • Exposes information, rather than hiding it
    • Prohibits natural changes to superclass
  • Use forwarding to avoid open recursion

[Bloch,Szyperski]

    • Gives up benefits of open recursion
  • Can we get the benefits of open recursion without the reasoning costs?
outline17
Outline
  • The Fragile Base Class Problem
  • Selective Open Recursion
  • Implementation & Analysis
  • Discussion
selective open recursion
Selective Open Recursion

Use open recursion only where necessary

  • Hook methods
    • Use open modifier on method
      • Expresses “hook method” intent
    • All calls to open methods dispatched dynamically
      • Just as in Java today
selective open recursion19
Selective Open Recursion

Use open recursion only where necessary

  • Hook methods
    • Use open modifier on method
      • Expresses “hook method” intent
    • All calls to open methods dispatched dynamically
      • Just as in Java today
  • Other methods
    • Calls to non-open methods on this dispatched statically
      • The only change vs. Java
      • Hides internal calling patterns from subclasses
    • Other calls dispatched dynamically
      • open≠ virtual
selective open recursion examples
class Set {

void add(Object o) {

// adds an element

}

void addAll(Collection c){

foreach (Object o in c)

this.add(o);

}

}

add is not open, so subclass cannot intercept and depend on the call. Set can change without affecting subclasses.

Selective Open Recursion Examples
selective open recursion examples21
class Set {

void add(Object o) {

// adds an element

}

void addAll(Collection c){

foreach (Object o in c)

this.add(o);

}

}

add is not open, so subclass cannot intercept and depend on the call. Set can change without affecting subclasses.

class Set {

// invoked for each add op.

open void add(Object o) {

// adds an element

}

void addAll(Collection c){

foreach (Object o in c)

this.add(o);

}

}

add is open, indicating the developer’s intent to expose this method as a semantic event to subclasses. Any changes to class Set must preserve these semantics.

Selective Open Recursion Examples
design principles
Design Principles
  • Non-open as default
    • Only use open recursion when explicitly intended
design principles23
Design Principles
  • Non-open as default
    • Only use open recursion when explicitly intended
  • Annotate the method, not the call
    • Design intent is attached to operation
do you have to change the language
Do you have to change the language?
  • Coding guidelines
    • Never call a public method on this
    • Hook methods should be protected
    • Non-hook, protected methods should be final
  • Not our idea
    • Suggested by Ruby & Leavens
    • Used extensively in JDK libraries
do you have to change the language25
Do you have to change the language?
  • Coding guidelines
    • Never call a public method on this
    • Hook methods should be protected
    • Non-hook, protected methods should be final
  • Not our idea
    • Suggested by Ruby & Leavens
    • Used extensively in JDK libraries
  • However—
    • This solution relies on programmer discipline
    • Language integration provides automated checking
outline26
Outline
  • The Fragile Base Class Problem
  • Selective Open Recursion
  • Implementation & Analysis
  • Future work and Conclusion
implementation in java
Implementation in Java
  • Extension to Barat compiler
    • Bokowski & Spiegel
  • Rewrite calls to non-open methods on this
    • Call a final method with the implementation for the current class
  • Available at http://www.archjava.org/
open recursion inference
Open Recursion Inference
  • Analysis to compute open annotations
    • Method m in class C must be open if:
      • Method m’ in class C’ <= C calls this.m
      • Class C’’ <= C’ overrides m
      • Class C’’ inherits or super-calls C’.m’
open recursion inference29
Open Recursion Inference
  • Analysis to compute open annotations
    • Method m in class C must be open if:
      • Method m’ in class C’ <= C calls this.m
      • Class C’’ <= C’ overrides m
      • Class C’’ inherits or super-calls C’.m’
  • Results may be imperfect
    • Assumes whole program is available
      • Misses open methods that are not overridden
    • May mark methods open that should be refactored to be non-open
experiments
Experiments
  • Ran open recursion inference
    • java.* packages in JDK 1.4.2
      • Except java.nio, java.sql (see paper)
experiments31
Experiments
  • Ran open recursion inference
    • java.* packages in JDK 1.4.2
      • Except java.nio, java.sql (see paper)
  • Hypotheses
    • Open recursion is rarely needed
    • Selective open recursion enables more optimization
frequency of open recursion
Frequency of Open Recursion
  • 9897 methods in our portion of stdlib
  • 246 (2.5%) of methods were inferred open
frequency of open recursion33
Frequency of Open Recursion
  • 9897 methods in our portion of stdlib
  • 246 (2.5%) of methods were inferred open
  • Maybe the stdlib doesn’t use inheritance
    • 1394 of these methods are overridden
    • Only 18% of these are open

Open recursion is rarely needed

Thus making it selective may enable substantial information hiding

frequency of open recursion34
Frequency of Open Recursion
  • 9897 methods in our portion of stdlib
  • 246 (2.5%) of methods were inferred open
  • Maybe the stdlib doesn’t use inheritance
    • 1394 of these methods are overridden
    • Only 18% of these are open
  • Open recursion is rarely needed
    • Thus making it selective may enable substantial information hiding
optimization potential
Optimization Potential
  • 22339 calls in our portion of stdlib
  • 6852 self-calls
    • 716 to open methods
      • Must be dynamically dispatched
    • 6136 to non-open methods
      • Can be inlined in our proposal (27% of total calls)
      • Inlining in Java would require private, final, or whole-program analysis
outline36
Outline
  • The Fragile Base Class Problem
  • Selective Open Recursion
  • Implementation & Analysis
  • Future Work and Conclusion
future work application to formal reasoning
Future Work: Application to Formal Reasoning
  • Formalizing as Featherweight Java + module system
future work application to formal reasoning38
Future Work: Application to Formal Reasoning
  • Formalizing as Featherweight Java + module system
  • Goal: bisimulation-based proof technique for showing contextual equivalence of modules in the presence of inheritance
future work application to formal reasoning39
Future Work: Application to Formal Reasoning
  • Formalizing as Featherweight Java + module system
  • Goal: bisimulation-based proof technique for showing contextual equivalence of modules in the presence of inheritance
  • Use selective open recursion and other techniques to provide more information hiding
    • i.e. prove more programs equivalent
conclusion
Conclusion
  • Open Recursion complicates reasoning
    • rarely used in practice
  • Selective open recursion
    • retains benefits of open recursion where needed
    • avoids fragile base class problem
    • can be efficiently inferred
    • may allow more optimization and reasoning
open recursion42
class Set {

void add(Object elem) {

// adds an element

}

void addAll(Collection c) {

foreach (Object o in c)

this.add(o)

}

...

class CountingSet extends Set {

private int count;

void add(Object elem) {

super.add(elem);

count++;

}

void addAll(Collection c){

super.addAll(c);

count+=c.size();

}

int size() { return count; }

// other functions

}

Open Recursion

Calls to this are dispatched to

subclass

Thus subclass can tell exactly

when each method is called