in a world where bindings and values immutability
play

In a world where bindings and values Immutability: obstacle or tool? - PowerPoint PPT Presentation

9/22/15 In a world where bindings and values Immutability: obstacle or tool? are immutable Discuss based on: Have you noticed? Programming experience in 251 and previously Readings


  1. 9/22/15 “In ¡a ¡world ¡where ¡bindings ¡and ¡values Immutability: obstacle ¡or ¡tool? are ¡immutable…” Discuss ¡based ¡on: • Have ¡you ¡noticed? – Programming ¡ experience ¡in ¡251 ¡and ¡previously – Readings ¡ about ¡language ¡ implementation ¡ and ¡GC • Patterns ¡for ¡accumulating ¡results (when ¡your ¡Java ¡brain ¡says ¡"x++", ¡etc.): • Efficiency? – Build ¡result ¡recursively • Reliability? – Create ¡fresh ¡copy ¡ • Ease ¡of ¡making/avoiding ¡ mistakes? – "Thread ¡state ¡through" ¡in ¡the ¡style ¡of ¡foldl • Clarity? • Small ¡function ¡"does ¡one ¡step" • ... • HOF ¡passes ¡result ¡on ¡to ¡the ¡next ¡step. • Try ¡for ¡at ¡least ¡3 ¡pros ¡and ¡3 ¡cons;Ϳ ¡OK ¡to ¡disagree. Cannot ¡tell ¡if ¡you ¡copy Suppose ¡we ¡had ¡mutation… (define (sort-pair p) (define x (mcons 3 4)) (if (< (car p) (cdr p)) (define y (sort-pair x)) p 3 4 x (cons (cdr p) (car p)))) ? ; mutate car of x to hold 5 y (set-mcar! x 5) (define (sort-pair p) ? 3 4 (if (< (car p) (cdr p)) (define z (mcdr y)) (cons (car p) (cdr p)) • What ¡is ¡ z ? (cons (cdr p) (car p)))) – Depends ¡ on ¡ sort-pair implementation Without ¡mutation , ¡these ¡two ¡implementations ¡are ¡indistinguishable • Document ¡ and ¡be ¡ very careful. – Change ¡at ¡any ¡time ¡without ¡introducing ¡ bugs ¡outside. • Changing ¡ implementation ¡ requires ¡changing ¡ uses Motivating ¡ examples/slides ¡adapted ¡ from ¡Dan ¡Grossman This ¡code ¡ is ¡close ¡ to ¡(but ¡ not ¡quite) ¡ working ¡ Racket… 1

  2. 9/22/15 An ¡even ¡better ¡example Java ¡security ¡nightmare ¡(really ¡happened) class ProtectedResource { (define (append xs ys) private Resource theResource = ...; (if (null? xs) private String[] allowedUsers = ...; ys public String[] getAllowedUsers() { (cons (car xs) (append (cdr xs) ys)))) return allowedUsers; (define x (list 2 4) } (define y (list 5 3 0)) public String currentUser() { ... } (define z (append x y)) public void useTheResource() { 2 4 x for(int i=0; i < allowedUsers.length; i++) { if(currentUser().equals(allowedUsers[i])) { y 5 3 0 ... // access allowed: use it 2 4 z return; ? or } } 2 4 x throw new IllegalAccessException(); y 5 3 0 } } 2 4 5 3 0 z Mutant ¡users! A ¡biasing ¡on ¡aliasing The ¡problem: Immutability p.getAllowedUsers()[0] = p.currentUser(); Aliasing ¡choices ¡ do ¡not affect ¡correctness, ¡just ¡performance. p.useTheResource(); Other ¡code ¡ can’t break ¡your ¡code. Changing ¡your ¡choice ¡ can’t break ¡other ¡code. Document ¡what, ¡ not how. The ¡fix: Start ¡with ¡safety, ¡optimize ¡for ¡performance. public String[] getAllowedUsers() { … return a copy of allowedUsers … Mutability } Aliasing ¡choices ¡ do affect ¡correctness ¡and performance. Other ¡code ¡ can break ¡your ¡code, ¡depending ¡ on ¡your ¡choice. Could ¡this ¡happen ¡ without ¡mutability? Changing ¡your ¡choice ¡ can break ¡other ¡code. Document ¡what ¡ and how. Start ¡with ¡performance ¡(maybe), ¡optimize ¡for ¡safety. 2

  3. 9/22/15 A ¡broader ¡PL ¡theme: • Limiting ¡how ¡programs ¡can ¡be ¡ expressed ¡can ¡be ¡very ¡useful! • Not limiting ¡ what computable ¡functions ¡ can ¡be ¡implemented, ¡just ¡ how . • Less ¡is ¡more ¡(reliable)? 3

Recommend


More recommend