To all --

Again, let me draw everyone's attention to the PIE papers of 
Goldstein and Bobrow from PARC ca 1980. One of them -- "A Layered 
Approach to SW Design" (or some such title) -- has some really 
interesting discussions about other approaches to system contexts -- 
and this paper (or one of the other ones) shows a browser they 
designed to deal with the different layers, etc. I remember them 
using this browser over the LAN at PARC to allow several different 
programmers in different locations to resolve conflicts 
collaboratively.

P.S. I don't want to open up a can of worms here, but I think there 
is a deeper way to approach the problems that the current various 
module suggestions -- piggy-backed on a 27 year old architecture on a 
30 year old language -- are trying to solve.
      I think a fresher look at identity and meaning plus a 
reinvolvement with message-sending could reveal new insights.
      For example, for a little while, forget about some of the old 
resuse and space-saving needs from long ago. What we really need to 
know about objects when programming is whether they are truly 
referentially transparent or not -- that is, can they substitute for 
other objects in variables or not? Similarly, from the variable POV, 
are our intentions about variables (with regard to objects they might 
contain) consistent?
      In an object system with polymorphism, this can extend over many 
classes that are deemed substitutes for each other. When we make 
changes, we need to know (a) whether the substitution invariants are 
being perserved or not, and (b) whether the change will force us into 
forking a class or not. One way to use the word "type" is to talk 
about these equivalencies (but I think a new term should be made up 
that isn't burdened with previous meanings).
      In an additive system, with type agreement, we can take an 
outside module and freely merge it with the base system. If a class 
from outside is meant to be an improvement in kind of a base class, 
but still has type agreement, then it can replace the base class, 
possibly with some reshaping of existing instances.
      It seems to me that most of the nasty problems with modules are 
ones where the new class and its use actually change the meaning of 
the class it overrides, especially when there are extant instances 
that are already in use. Simula 67 had the idea of virtual procedure 
where a method of a subclass would be substituted for a deep method 
in a superclass. Smalltalk provides the opportunity to always do this 
but sending a message to self. There is no mechanism in either of 
these two languages that helps establish whether the overriding 
method has any validity (Simula does protest type conflicts in the 
parameters). Eiffel has some important ideas about constraining 
subclasses to not changes species. Etc. The module problem is a 
superset of virtual procedures. I don't thing any module "solution" 
that doesn't have good strategies to deal with extant instances is 
going to stand up.
      This is where new approaches to identity may be required and 
useful. For example, there is no question that two Squeaks can 
interoperate via message-passing if they are on two different 
machines or in two different address spaces on the same machine. Here 
are modules in the large. What if we want to have a little more 
control and understanding of when it is appropriate to send a 
particular message (and especially by sending particular objects as 
parameters)? Existing mechanisms don't deal very well with these 
cases in which meaning is what we are trying to determine and compare.
      We could make up a term called "congruence" for some better way 
to establish degrees of equivalence than signatures or interfaces. 
There needs to be more semantics in congruence than the simple 
matching that most systems do now.

What are some good ways to do this?

Cheers,

Alan

-----

At 3:10 PM +1300 3/4/02, Richard A. O'Keefe wrote:
>How about
>(a) Making the change-set browser-specific, and
>(b) Having the browser display the change-set in its title-bar.


--