ReRe: why isolated components

[Vance Shipley]

One problem which is hard to eliminate is that people will make
assumptions.  You can obey the contract but ignore the intention.

The discussion about file descriptors comes to mind.  If we peek
into the token we are passed on an open() we can start to make 
assumptions about what to expect and can cheat in how we deal
with them.  Every time I see code like this I smell trouble:

	fd = open(...)

	foo[fd] = ...

One might just start doing this:

	for (i=first_fd; i <= last_fd; i++)
		write(i, ...)

or
	number_of_files = last_fd - stderr

It might appear to work most of the time.  Further if a black box
is always observered to behave in a certain way it will often be
assumed that it should always behave that way.  After a while it
becomes expected and systems are built to depend on it and eventually
someone puts it in a standard.

Maybe the contract checker should mangle handles so they are 
unobservable.  The addition of state to the type system goes a long
way to define the other behaviour.

	-Vance

On Fri, Aug 22, 2003 at 04:26:04PM +0200, Joe Armstrong wrote:
}  
}    Inside a BB you might program in assembler (whatever) break all rules of
}  common-sense etc. But "at the door" - when you pass in or out of the
}  BB you *must* obey the protocol. Observational equivalence applies.
}  Any two BBs that behave the same way ARE equivalent.