Path: utzoo!attcan!uunet!mcsun!ukc!newcastle.ac.uk!turing!ncmh From: Chris.Holt@newcastle.ac.uk (Chris Holt) Newsgroups: comp.lang.misc Subject: Re: Request For Comment About Handling Of Globals Message-ID: <1990Nov30.191454.29030@newcastle.ac.uk> Date: 30 Nov 90 19:14:54 GMT References: <242@smds.UUCP> <252@smds.UUCP> Sender: news@newcastle.ac.uk Organization: Computing Laboratory, U of Newcastle upon Tyne, UK NE1 7RU. Lines: 43 In article pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: [lots of interesting reasons why scoping should be changed from the standard way] Purists have long maintained that anything in one part of a program should be explicitly imported or exported if it is to be visible in another (remember Dijkstra's glovar declarations?). This has never taken off because in real life the number of things that need to be redeclared over and over again is enormous; and really important things can be remembered anyway (at least when writing the code :-). Well, I tend to view objects as 3D structures, e.g. spheres, that have windows in them. Two spheres can be linked together by connecting their windows; then they can see into each other, to a greater or lesser extent (since windows only allow certain things to be seen; they show restricted views). A window may be one-way, rather than two, so you can only see out, or only see in. That is, the user should be able to specify which way scoping works; there may be a default, but it should be under the programmer's control. Furthermore, windows don't have to be just on the surfaces of objects, linking them with their direct (3D) environments. If a module A is linked with B, and B is linked with C, then B should be able to introduce A and C so they each have a window directly to the other, without going through B (this is useful if B decides to terminate before A and C are done). So, once a module has been introduced to a given library object, they can talk without going through the entire hierarchy; they go through the "hyperwindow" connecting them. This approach encourages small interfaces; no object wants another object looking directly at its variables (unless they're in love :-), and each object only sees those windows of other objects that it has been introduced to (what's a nice object like you doing in an environment like this?). The scope of a method becomes a graph, with each method having a different scope. Oh well; just a thought. ----------------------------------------------------------------------------- Chris.Holt@newcastle.ac.uk Computing Lab, U of Newcastle upon Tyne, UK ----------------------------------------------------------------------------- "He either fears his fate too much, or his programming tools are small..." Brought to you by Super Global Mega Corp .com