As you get deeper in the application (Call stack bigger) you will reach code that knows how to talk to the people, or their agents, about their auction status. At this point the opaque capabilities that designated bidders may well be discriminated so as to speak the correct natural language to the bidder, and send such messages to the correct geographical place. Much software today expects ambient authority to write on a screen. Asking one of many bidders for information doesn’t fit this well. Fluid variables are perhaps a crutch to provide ambient authority without really doing so. The idea of an amorphous set of authority to contact the bidder is indeed necessary. I think indeed there should be a bundle—an object per bidder that provides this authority, whereas the fluid variable scheme that I think I have understood provides for exactly one such bundle. Now auction logic can keep lists or arrays of such bundles. For the scope of the next few paragraphs Let me call such a bundle a fuzzy object. It is not really fuzzy but its real interface is unknown to the bulk of programs that pass it around; to them it serves only to identify the bidder.

The fuzzy object comes into better focus as we move towards the software that is people savvy. Eventually the fuzzy object is not fuzzy and the real people interactions take place.

Designs with which I am most familiar fit the pattern that if A invokes B then B is likely to be more primitive than A, indeed B was probably designed and coded first. There have always been prominent exceptions. The fuzzy object concept is an admission that there are complexities very deep in the application that the “higher levels” are not cognizant of. All of this is wrapped up in that mysterious agendum that flits about the machine following messages. Why are we taking this action, and what has the call stack to do with it? Rick Mascitti said that the call stack is that part of the past that is relevant to the future. (In the same context he noted that a copy of the stack was a good embodiment of Scheme’s continuation.)

I know that E discourages many stack use patterns. That fits somewhere here.

These ideas suggest that code to which people-capabilities are opaque, should be unable to invoke those capabilities. I agree that that would prevent a class of bugs. I hesitate because of the cost of the mechanism and also that it is not properly a security concern. Dick Gruen once proposed that the property ascribed to a person that allowed him to meddle in some aspect of a computer system be called “license” rather than “privilege” or “status”, especially when the policy stemmed from keeping people from causing problems thru lack of knowledge or skill. We might call the ability to invoke people objects license instead of authority even if were implemented with exactly the same mechanisms.

Since this is sort of about the evils of global variables I quote from Getting Started with Netscape JavaScript Debugger:

NOTE: When you’re stopped in Netscape JavaScript Debugger, you cannot use many features of Communicator. In particular, you cannot use Navigator to browse web pages. For this reason, it is recommended that you download the PDF version of this document before starting the debugger. You can then either print that document or view it online with Acrobat Reader.