Environmental Acquisition: What's it good for, really?

April 13, 2004

Presented by: Richard Cobbe

Notes by: Greg Pettyjohn

1  Gil and Lorenz

Richard introduces acquisition via a comparison with inheritance. Inheritance is the traditional OO abstraction mechanism, where classes inherit some of their properties from other classes according to the class hierarchy. With acquisition, objects acquire properties from their environment.

Richard gives an example of a vehicle with a color property and door property.

abstract class Vehicle { ... }

class Car extents vehicle {
   Color c;
   Door d;
...
}

class Airplane extends vehicle {
   Color c;
   Door d;
...
}

class Door { ... }

In the example, instances of the Car class and instances of the Airplane class will each be containers for instances of the Door class. Instances of the Door class will then be able to acquire properties from their containers.

The notion of ``environment'' is developed further. For the purpose of acquisition, containment relationships are used to determine the objects environment. In contrast, objects may have other relationships such as collaboration. The model view controller pattern is one example of object collaboration, where neither the model nor the view is contained in the other.

The following assumptions are made about containment:

  1. Each object has a unique container

  2. No cycles allowed in the containment relation

  3. General - any object can be contained

The speaker poses the following question:

What if an object does not yet have a container? E.g. car door on the factory floor has never been part of a completed car.

This question motivates the addition of means for assignment of default values to object properties which can otherwise gain their values through acquisition. Two ways of doing this are proposed. The first is to provide a default value in the acquiring class declaration. The second is to provide a ``guard'' syntax:

MyDoor.color guard blue;

Here the guard ensures that references to MyDoor's color attribute will be defined (and equal to blue), even when the door does not have a clear acquisition for the color.

Alternatively, if we can statically verify that the door always belongs to some container, then we don't need defaults or guards. Two acquisition relations are introduced. The must containment relation c1 < c2 indicates that an instance of class c1 must be contained in an instance of class c2. The may containment relation c1 << c2 indicates that an instance of c1 may be contained in an instance of c2.

The speaker argues that << is not a useful relation because it isn't restrictive enough.

Jeff Palm suggests that it may still be useful, because then we at least know where an object won't be used.

Ryan Culpepper asks whether the paper explained how the << was intended to be used i.e. whether the paper motivated its existence.

Richard responded that the paper did not provide enough formality to establish the usefulness of the relation.

Richard also dismisses < because it is too restrictive. In the car door example, we cannot prove that Door < Car or Door < Airplane so it may still be safe to omit checks.

The Gil and Lorenz paper uses several examples to motivate environmental acquisition. The speaker states that the strongest example was Borland's Turbo-Vision, a gui toolkit. Richard provides a dialog containing multiple widgets is provided as an example. Here is the aggregation tree, which describes the containment hierarchy for the dialog:

dialog
   panel
      checkbox
      checkbox
   button
   button
   button

The speaker then illustrates what happens when a modal component is added as a child of the dialog:

dialog
   panel
      checkbox
      checkbox
   button
   button
   button
   modal

The modal component is the only active component and all other widgets that belong to the dialog are deactivated, i.e. they don't respond to user events. So the other child components must acquire the event handler from the parent dialog.

At this point, Dave Herman asks if an object can also acquire event handlers? A: yes

Same Tobin-Hochstadt asks if we lose local reasoning? A: yes (This touched off a somewhat tangential discussion which I have omitted.)

Daniel Silva: How does error handling compare with PLT Scheme's parameterize? A: Could be different, parameterize is based on threads, while the error handling in the example would be based on window containment.

2  Zope

Zope is a web publishing tool intended for developing web services. Amazon.com is offered as an example of a web service, but it is noted that Amazon is likely to large a system to be successfully implemented using Zope.

Zope organizes the components of a web service in a hierarchical directory format.

Zope
   Book_Sales
      book_hello.html
      <more ...>
   Train_Schedules
      <more ...>
   hello.html

Zope uses a ``message passing'' paradigm. Messages are represented by URLs, where the path portion of the URL references a particular node in the Zope hierarchy. Examples:

http://foo.com/hello.html
http://foo.com/BookSales/book_hello.html
http://foo.com/BookSales/hello.html

Observe that the third URL does not actually reference an existing node in the hierarchy. This provides the example for how acquisition works in Zope. Although BookSales does not have a hello.html child, it may acquire the hello.html from another node by moving up in the hierarchy.

Question: Why can't this be cast as inheritance rather than acquisition?

A: Good Question. It probably could, however, Zope defines inheritance to be something completely unrelated. In the example, both Zope and BookSales are ``instances'' of the ``folder'' class.

Richard argues that Zope uses acquisition because it is devoid of any other abstraction mechanism. This suggests that Zope may not be the right example to justify acquisition.

Felix Klock asks why it is necessarily bad that this is the only abstraction mechanism?

This question motivates the next part of the talk. In particular, Richard points out that when acquisition is the only abstraction mechanism, shared behavior must be placed at the least upper bound of the nodes that acquire the behavior. This will tend to push abstractions up in the tree where they will also become visible to other nodes that perhaps shouldn't have access to them.

Sam Tobin-Hochstadt and Felix Klock are not totally convinced that this is so terrible. They point out that lexical scoping has analogous behavior.

3  Anomaly

Anomaly is a domain specific language for network administration. Components in a network exist in a context. For example, a computer that sits on a faculty desk has a different policy than on in a public lab.

The speaker provides the following Anomaly example:

room CN201
{
   Access Policy (...);
}

room Egan222
{
   Access Policy (...);
}
CN201 contains
{
   Sualocin;
   ...
}
Egan222 contains
{
   Sulafat;
   ...
}

Next, the scenario where a computer is moved from one place to another is shown. When the computer changes location, it must automatically pick up changes based on its new location. This is an application of acquisition:

group Solaris {
   pkgs ...
}

group Beta {
   pkgs ...
}

Solaris contains
{
   Sualocin;
   Beta;
}

Beta contains
{
   Sulafat;
}

One difference from the other examples of acquisition given thus far is that objects may now belong to multiple containers. This could potentially cause problems when an object can acquire the same property from more than one context. In Anomaly, such an error can be detected at compile time and reported before it causes trouble.

Last modified: Tuesday, April 13th, 2004
HTML conversion by TeX2page 2003-09-27