Re: How does one model behavior?

On Wed, 09 Apr 2008 05:04:10 GMT, David Cressey wrote:

> How does one model behavior?

Behavior of what? Of the program, of a physical system?

> It would seem to me that, since conveying behavior from one object to
> another rests on messages, and since messages are made of data, that one
> needs a data model for the messaging system before one begins to come up
> with a bhavior model for a system of collaborating objects.

> Or is there another completely different way of setting things up?

Yes, messages are just certain kinds of operations built upon something else. Thus in my view OO is not about messaging and messaging is not all behavior.

To your point about messages parameters. Yes, you could try to treat them as data. But that would not solve the problem of defining the behavior of these "data."

Further there is no difference between the message parameters and the message's recipient. They all are values of some types. So the message X sent to T with a parameter V is simply an operation X defined on both types T and V. Neither is better than another, they are equal.

Mutability is not an issue here. When the recipient of the type T is mutable, then X is defined as

   X : T x V -> T

Any mutable operation can always be described in an immutable way. You just bind one in- and one out-parameter to the same object.

Certainly the behavior of some types is derived from / defined by the behaviors of others. Surely there could be predefined types of which values behavior is postulated. Moreover, it has to be done, not only for mathematical reasons. The advantage of not inferring behavior is huge. You can have all sorts of hardware, remote/software components behaving as a "random number," as a "clock," as a "real number," as, for that matter, an RDBMS, without deducing that. This is why OO shines in large, complex, mission-critical software design. In short it is called separation of implementation and interface.

Returning to your point, you need a type system prior both messaging and data.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de