1 / 10

Challenges in Block Structure: Understanding Side Effects, Vulnerability, and Access Control

Explore the issues related to side effects, indiscriminate access, vulnerability, and overlapping definitions in block structure programming. Learn about Wulf and Shaw's alternatives and directions to address these problems effectively. Discover the importance of decoupling access to objects and their implementations, and the significance of varying access rights. Consider the need for encapsulation in programming languages and the debate surrounding block structure.

mcneills
Download Presentation

Challenges in Block Structure: Understanding Side Effects, Vulnerability, and Access Control

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

  2. (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

  3. 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

  4. (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

  5. (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.

  6. 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…

  7. (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

  8. 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?

  9. 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...

  10. 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??

More Related