1. A Seminar on Encapsulation http://www.cs.tau.ac.il/~msagiv/courses/encapsulate.html Noam Rinetzky Mooly Sagiv Summary

2. Outline 1.Formalisms in programming languages 2.What is encapsulation 3.Some model of encapsulation 4.Feedback

3. Programming Language Formalisms Regular languages Context free grammars Attribute grammars Operational Semantics Axiomatic Semantic/ Deductive Verification Denotational semantics Type Checking Abstract Interpretation

4. Example: The While Programming Language S::= x := a | skip | S1 ; S2 | if b then S1 else S2 | while b do S

5. Natural Semantics Notations – - the program statement S is executed on input state s –s representing a terminal (final) state For every statement S, write meaning rules  o “If the statement S is executed on an input state i, it terminates and yields an output state o” The meaning of a program P on an input state i is the set of outputs states o such that  o The meaning of compound statements is defined using the meaning of immediate constituent statements

6. Natural Semantics for While [ass ns ]  s[x  A  a  s] [skip ns ]  s [comp ns ]  s’,  s’’  s’’ [if tt ns ]  s’  s’ if B  b  s=tt [if ff ns ]  s’  s’ if B  b  s=ff axioms rules

7. Natural Semantics for While (Loop rules) [while tt ns ]  s’,  s’’  s’’ if B  b  s=tt [while ff ns ]  s if B  b  s=ff

8. Hoare Proof Rules for Partial Correctness {p} skip {p} {p/v  e } v:=e {p} {p} c 0 {r} {r} c 1 {q} {p} c 0 ;c 1 {q} {p  b} c 0 {q} {p  b} c 1 {q} {p} if b then c 0 else c 1 {q}

9. Hoare Proof Rules for Partial Correctness {i  b} c {i} {i} while b do c{i  b}  p  p’ {p’} c {q’}  q’  q {p} c {q}

10. Type Checking Rules   intconst: int   realconst : real   e1 : int,   e2 : int   e1+e2 : int   e1 : real,   e2 : real   e1+e2 : real   e : t   id = e : void  (id) = t   e : int   e : real

11. Type Checking Rules Enforce consistency of usages Many satisfying type assignments Most principle type Sound type system –Every type assignment describes a superset of expression values

12. Even/Odd Abstract Interpretation Determine if an integer variable is even or odd at a given program point

13. Example Program while (x !=1) do { if (x %2) == 0 { x := x / 2; } else { x := x * 3 + 1; assert (x %2 ==0); } } /* x=? */ /* x=E */ /* x=O */ /* x=? */ /* x=E */ /* x=O*/

14.   Abstract Abstract Interpretation Concrete  Sets of stores Descriptors of sets of stores 

15. What is encapsulation?

16. Common Answer(1)  Encapsulation is the ability of an object to place a boundary around its properties (ie. data) and methods (ie. operations)  Programs written in older languages suffered from side effects where variables sometimes had their contents changed or reused in unexpected ways. Some older languages even allowed branching into procedures from external points  This led to 'spaghetti' code that was difficult to unravel, understand and maintain  Encapsulation is one of three basic principles within object oriented programming languages

17. Common Answer(2)  Object variables can be hidden completely from external access  These private variables can only be seen or modified by use of object accessor and mutator methods  Access to other object variables can be allowed but with tight control on how it is done  Methods can also be completely hidden from external use  Those that are made visible externally can only be called by using the object's front door (ie. there is no 'goto' branching concept).

18. Is it that simple? Does private guarantee encapsulation?

19. What is encapsulation? Desired feature of programs/systems Not well defined

20. What is encapsulation? Restrictions on aliasing Desired features –Modular reasoning –[Representation independence] –Simplified specifications Predictable side-effects –[Simplified concurrent programming] –Not too restrictive Enforced –Programming disciplines –Programming language syntax –Runtime checks –Type system –Abstract interpretation

21. Towards a Model of Encapsulation J. Noble, R. Biddle, E. Tempero, A. Potanin, D. Clark

22. Dan Ingalls “No component in a complex system should depend on the internal details of any other components”

23. Access Graph Models the topology of the system –Nodes N –Edges E between nodes represent accesses between objects Either directed or undirected Abstract Simple example: Storage graph

24. Encapsulation Function A system S  N An encapsulated component C –Can be a package –A set of objects Map C into three sets –B the Boundary nodes –Y the Inside nodes –R the External nodes referred –O the Outside nodes –O = S – (B  I) –R  O –e: C  {B, I, O}

25.  An encapsulated component   B I  R O

26. Encapsulation Constraints Disjointness of sets –B  I =  –B  R =  –I  R =  Connectivity –  {I}  (B  I) –  o  O,  i  I :  p  paths(o, i):  b  p s.t. b  B –(B  I)   (B  I  R) “No component in a complex system should depend on the internal details of any other components”

27.  Nested Encapsulation   BdBd IdId  RcRc O BcBc IcIc  RdRd 

28. d is nested c (d  c) when –I d  I c –B d  B c  I c –R d  B c  I c  R c

29. Islands: Full Encapsulation Hogg[Aharon]  I  R B

30. island(o) = B = {o} I = {o}  R= {o}  where bridge(o) Protects static references only Syntactic enforcement

31. Uniqueness unique B I R

32. Uniqueness unique(u) = B =  {u} I = {u} R= O where |  {u}| = 1 Can be enforced by 1. Runtine 2. Type system 3. Abstract Interpretation

33. External Uniqueness Clarke&Wrigstrad [Ziv]

34. external_unique(u) = B = v I = {u}  {o| u  o } R= O where v =  {u} –I |v|= 1

35. Balloon Types [Alemida] R outer R inner I outer I inner B inner

36. Flexible Alias Protection Noble, Vitek, Potter More permissive than Islands and Balloon on static alias protection Adds requirements on dynamic aliases Two concepts: representation and arguments o rep(o)arg(o)

37. Ownership Types Clarke, Potter, Noble [Shay, Sharon, Ziv] Alias protection via ownership Every object has an owner –ownership forms a tree Only references from parent to decedents Nested encapsulation Enforced by the type system

38. Ownership

39. Formalizing Simple Ownership owner: N  N owner(root)=root i ownedby o =  k: owner k (i) = o o owns i =  k: owner k (i) = o Invariant: s  t  s ownedby owner(t) simple-ownership(o) = B = {o} I = {i | o owns i } R= {r | o ownedby owner(r) }

40. Other Ownership Models Parameterized ownership –The set R is explicitly parameterized by ownerships Inner Ownership [Boyapati]

41. Confined Types Bokawski&Vitek [Guy]

42. package: N  C confined(p) = B = {o| packge(o=p  confined(o)} I = {i | packge(o=p  confined(o)} R= O

43. Lecture Summary

44. Feedback