How does one model behavior?

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?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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