Packages Inside Classes? Design questions
Semantics | Home

  The Question

Any named element can be a member of a capsule.

(1)

This means that packages can be members of classes. For example, the following is currently legal: 

Class C
     public:
       Package C.p
         public:
           Variable C.p.v : C
         private:
     private:

Should we allow this? What does it mean? There are three alternatives.

  Option 1: All packages are static

One reasonable answer to our question is that packages should always be static, and their members should always be global. Under this scenario, in the example above, there would be one C.p.v for the whole program -- C.p.v is a global variable which happens to sit inside C's namespace.

Advantages: This is the alternative which most people intuitively jump to. It solves the problem of static class members without the need for creating additional language structures.

Disadvantages: It's not clear that this really solves the static member problem. Consider the following simple Java class: 

public class Happy
	{
	public static Happy getHappyFromName(String name)
		{
		return nameTable.get(name);
		}
		
	private static Map nameTable;
	
	public setName(String name)
		{
		nameTable.add(name, this);
		}
	}

If Eidola creates static members through packages, this becomes quite messy. The following obvious approach won't work: 

   Class Happy
     public:
       Package Happy.static
         public:
           Function Happy.static.getHappyFromName
             ...
         private:
           Variable Happy.static.nameTable : Map
       Function Happy.setName
         ...
     private:

The problem here is that Happy.setName needs to be able to see Happy.static.nameTable, but it's private to Happy.static. It's actually necessary to create two member packages to make this work: 

   Class Happy
     public:
       Package Happy.static
         public:
           Function Happy.static.getHappyFromName
             ...
         private:
       Function Happy.setName
         ...
     private:
       Package Happy.static2
         public:
           Variable Happy.static2.nameTable : Map
         private:

This does the trick, but its awkwardness suggests that packages aren't a great mechanism for handling static members.

  Option 2: All class members belong to an instance

Another alternative is to say that every member of a class is tied to an instance of that class -- a particular object -- including package members. Under this scenario, in our original example, there would be a C.p.v for every instance of C.

Advantages: This is more consistent with the nature of class membership, and with a package's simple role as a way of dividing up the namespace without otherwise changing meaning. It presents the intriguing possibility of encapsulating one section of a class from the rest of the class. This might be quit useful for classes with a large number of methods which fall into distinct categories.

Disadvantages: Packages would have to have signatures. Although this is easy enough in itself, it would have complexifying ramifications for the semantics, and for the kernel's event propagation scheme. In particular, it would remove the current nice property that events can't propagate more than one element beyond the boundaries of a class, because packages would have to relay signature changes to their owners.

Dividing up the methods of a bulky class might be a good task for a notation, although a notation couldn't provide real encapsulation.

  Option 3: Just disallow it

With an extra line in this semantics, we can just avoid all of this nonsense. But how boring is that?

  The Verdict for Now

Heck, we ain't even finished the evidentiary hearing yet. It will be illuminating to see what falls most naturally out of the runtime semantics.

  Design questions | Semantics | Home Copyright 2000-2001 Paul Cantrell