[MUD-Dev] Object Models

[Phillip Lenhardt]

On Wed, Nov 29, 2000 at 03:57:19PM -0800, John Buehler wrote:
> In our component approach, the development manager liked to use the phrase
> "throw away the sources" for what to do when a component ships.  He wanted
> components to be absolutely opaque.  There's no need to see into a component
> for integration purposes because you integrate at the level of public
> interfaces (a runtime consideration), and there's no need to see into a
> component for debugging purposes because there are no bugs (you wouldn't
> believe the verification process).

Forgive me for being so blunt, but this is insane. I'll try to provide an
example of why I think so, and so as not to appear unduly negative, suggest
an alternative answer to components:


Suppose you have a component called Sorter that takes an array of
Integers and a pointer/reference (or whatever your language supports)
to another component called Comparer and returns a "sorted" array
of Integers. Comparer takes two Integers as arguments and returns
a Boolean: True if the first Integer argument is greater than or
equal to the second Integer argument and False otherwise.

So the contract as I've stated it above guarantees that the right types
get passed in and the right types get returned. But how do you specify
in the contract that whatever algorithm Sorter uses actually returns
an Integer array such that if you passed the Nth and Nth + 1 elements
of the array to Comparer, the Comparer will return True (ie the array
is sorted in descending order)? You can't just analyze the algorithm
used by Sorter because that could very well be a non-terminating or
_very_ long process. I suppose you _could_ have a post-condition of the
contract actually do the comparison of the Nth and Nth + 1 elements for
every pair of elements in the array, but that's horribly inefficient.

There's a whole class of languages--Haskell, SML, Clean, etc--that
treat programs as a series of functions calling other functions. That's
"function" in the mathematical sense: the exact same input _always_
results in the exact same output; not just type-sameness, but value-
sameness. And none of those languages try to make sweeping guarantees
that the results you get will be the ones you want, just that you will
get the _same_ results every time you provide the same input. And
components can't make that weaker guarantee, even though you claim
they can enforce even stronger guarantees.
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev