100 likes | 108 Views
What's Wrong with Block Structure?. (Wulf, Shaw, SIGPLAN Notices, 1973, "Global Variables Considered harmful") Four (somewhat interrelated) problems: Side Effects Indiscriminate Access Vulnerability No Overlapping Definitions. (1) Side Effects. (hidden access to an object)
E N D
What's Wrong with Block Structure? • (Wulf, Shaw, SIGPLAN Notices, 1973, "Global Variables Considered harmful") • Four (somewhat interrelated) problems: • Side Effects • Indiscriminate Access • Vulnerability • No Overlapping Definitions
(1) Side Effects • (hidden access to an object) • e.g. proc/func that increments a non-local counter to track number of calls. • If counter happens to be a param then aliasing occurs
Possible outcomes: 2: x,y in regs; x stored in mem before y; 3: x, y in regs; y stored in mem before x; 4: neither in regs; x is 2 here; x := 2 + 2; Aliasing var y: INTEGER; PROCEDURE p1 (var x: INTEGER); BEGIN x:= 1; y:= 2; x:= y + x; END; BEGIN p1(y); END. x & y are same object
(2) Indiscriminate Access • (can't prevent access to an object) • e.g. trying to implement stack data type • stacks are visible to non-stack operations. Data Proc push; Proc pop; . . . Uncontrolled access to data representation
(3) Vulnerability • (a program segment can't preserve access to an object) • e.g.: int x; Procedure p1; { . . . x . . . } <---- Proc p0; float x; insertion of p0 cuts off p1's access to int x.
e.g. (recall) Pascal Scope Rules... Type T1 = ... . . . Procedure p1; Type T2 = <structure of> T1 -- *** T1 = . . . • which T1 is ref'd at *** ? • (A) T2's ref to T1 is to T1 in outer level • (B) T2's ref to T1 is to T1 in local level • Interpretation (B) is consistent with User Report, • But (A) is one usually used…
(4) No Overlapping Definitions • (No control over shared access to objects) • e.g.: Obj-1 Obj-2 P1 P2 P3 P4 • no nesting structure can give access only as desired. wanted not wanted
Wulf/Shaw Alternatives • There should not be implicit inheritance by inner levels: side effects, vulnerability and indiscriminate access result from implicit inheritance, although its removal, alone, does not fix whole problem. • Name access should be by mutual consent --solves indiscriminate access, vulnerability and overlap. • Access to an object and access to its implementation should be decoupled. • Access rights should have various allowable qualifiers (e.g. read only, write only, etc.) Inheritance?
Wulf/Shaw Directions • Declaration of a) definition, b) name access and c) allocation should be decoupled. • Typical block structure: • name declared by appearance in declaration • access determined by block structure • storage allocation determined by activations of context • Examples of decoupling we’ve seen so far: • ALGOL60 OWN allows control over allocation • (C static as well) • Dynamic data types (pointers) give allocation control • Others? ==> a clear motivation for encapsulation...
Consider... • Block structure persists, despite some strong arguments against it. Make an argument for its continued presence in programming languages, or propose and defend a replacement. -- thoughts??