ITEC 380 2008fall ibarland

home—info—lectures—exams—archive

lect09b
dynamic scope; access control reviewed

Java (with v1.5), anonymous inner classes have closures:

    import java.awt.*;
    import java.awt.event.*;
    
    class ButtonHolder {
      int m,n;
      Button b;
      
      
      ButtonHolder() {
        b = new Button();
        addOneListener();
        addOneListener();
        }
    
      void addOneListener() {
          
        b.addActionListener( 
          new ActionListener() {
            int n=0;
            public void actionPerformed(ActionEvent e) {
              ++n;
              ++m;
              }
            } );
            
          }
        
    
      // Now, imagine you make three new ButtonHolder()s,
      // and each ButtonHolder makes two of these anonymous inner classes.
      // How many n's?  How many m's?
      // Note that the instance of the ActionListeners are not fields
      // of ButtonHolder; their <em>closure</em> does include fields of ButtonHolder, though.
      // Also note that other parts of code (e.g. the awt event handler)
      // has references to the ActionListener, even though ButtonHolder() is not in its scope.
      }

Dynamic scope: (Lisp; Perl.)

class Foo() {
  int x = 3;

  void foo() {
    ++x;        // If dynamically scoped: refers to 'most recently declared' x
    print(x);   // in a *dynamic* sense!
    }

  void haha() {
    foo();
    }

  void lala() {
    int x = 9;
    foo();
    }

  void gaga() {
    int x = 5;
    foo();
    }

  }


class Hoo() {
  int x;
  Foo.foo();
  }

• Let a "set-of-bindings" be something where you can look up a name and get the associated value. (Might be a hashtable, or even just an association-list.)
• When a varible is encountered: try to look up in the stack's top set-of-bindings; if not found look in the next set-of-bindings, etc..
• Whenever new scopes are entered (via 'let' or via calling a function/parameters), push a new set-of-bindings onto the stack. Whenever leaving a scope, pop the stack-of-(set-of-bindings).

Other ways of controlling access:

• OO: public/private.
• Pascal, etc.: Nested functions/classes. Note that this is not commonly used these days: C doesn't allow nested functions; Java doesn't make big use of them. Sebesta §5.8.3 discusses drawbacks.
• Scheme, etc.: closures via returning several functions which share variables.
  (As we saw, this can implement a object system, somewhat.)
• Java, etc.: closures via inner classes
• packages (Java, e.g. java.awt.event.*), namespaces (incl. xml standard), modules (requires, provides).
  DrScheme also has “units” -- view a module as a function which takes in a bunch of (imported) functions, and returns a bunch of (exported) functions. E.g., a module can import a bunch container-methods (get, isEmpty, toString, etc.) and based on those export a new library/type/complete-set-of-functions. Usually, we think of modules as taking in one specific library rather than ‘any binding of the required names’.

home—info—lectures—exams—archive

©2008, Ian Barland, Radford University Last modified 2008.Oct.29 (Wed)

Please mail any suggestions (incl. typos, broken links) to iba�rlandrad�ford.edu