Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!rutgers!usc!wuarchive!uunet!bywater!arnor!minnow!artg From: artg@arnor.uucp Newsgroups: comp.lang.misc Subject: Re: Request For Comment About Handling Of Globals Message-ID: <1990Dec7.195140.3022@arnor.uucp> Date: 7 Dec 90 19:51:40 GMT References: <242@smds.UUCP> <252@smds.UUCP> <1990Nov30.191454.29030@newcastle.ac.uk> Sender: news@arnor.uucp (NNTP News Poster) Organization: IBM T.J. Watson Research Center Lines: 63 In article <1990Nov30.191454.29030@newcastle.ac.uk> Chris.Holt@newcastle.ac.uk (Chris Holt) writes: >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. Many good, practical reasons argue against global variables. Modules (objects or processes) sharing variables are constrained to run on the same machine unless the distributed system running under them implements shared memory. So sharing variables can prevent a distributed program from being reconfigured, and can make it impossible to do process migration. Sharing, and unconstrained module interface design, explains why computer software functionality and construction has progressed so slowly. My favorite analogy that suggests how software should be decomposed is electronic hardware. Electronics could not have made great strides without the clearly defined INTERFACES between components. Anyone who builds a memory chip that satisfies the interface specs -- physical dimensions (ie pinout positions), voltage levels, and logical behavior -- and improves on PERFORMANCE characteristics of the chip -- power consumption, failure rate, cost and response time -- will get others to use the chip. This lets loads of people and organizations specialize in memory chips and improve their quality. Digital logic's full of widespread and sensible interface requirements, from binary logic levels to addressing that uses a power of two bits. Software, meanwhile, seems to be ruled by the law "First interface to get market share wins", independent of quality. See MS-DOS, OS/360, kermit, Lotus-123, dBase, Unixes, etc. (If I haven't picked on you please dont feel left out. :-) ) My belief is that if programmers and system designers spent more time defining and PROGRAMMING the interfaces between separate modules, (and only shared data specified in the interfaces), then programs would plug together much more easily than they do today and programmers would benefit much more from each other's work. Languages therefore should be able to specify, independently of any program, the data that modules pass between themselves - its type, its degree of initialization, and other representation independent characteristics. Then modules should be composed, much in the way that chips are combined into ALUs, ALUs into boards, and boards into machines, etc., so that each composition can be defined by its set of interfaces with the outside, and the outside doesn't care about the implementation of a given composition. Arthur artg@ibm.com IBM Research Yorktown Heights