Block Structure (PPT)

Download Report

Transcript Block Structure (PPT)

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
Aliasing
var y: INTEGER;
PROCEDURE p1 (var x: INTEGER);
BEGIN
x & y are same object
x:= 1; y:= 2;
Possible outcomes:
x:= y + x;
2: x,y in regs; x stored
END;
in mem before y;
3: x, y in regs; y stored
BEGIN
in mem before x;
p1(y);
4: neither in regs;
x is 2 here;
END.
x := 2 + 2;
(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;
<---- Proc p0;
float x;
Procedure p1;
{...
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
wanted
not wanted
P1
P2
P3
P4
• no nesting structure can give access only as desired.
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.)
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??