Re: Object Class and Data Type

"Tom Hester" <$$tom_at_metadata.com> wrote in message news:a8b99$406a148a$45033832$30830_at_msgid.meganewsservers.com...

Just my $0.02 worth.

> No they are not the same. Perhaps understanding the difference should be
a prerequisite to
> contributing to a theory group. "[A type system is a] tractable syntactic
method for proving the
> absence of certain program behaviors by classifying phrases according to
the kinds of values they compute."
> (Types and Programming Languages, MIT Press, 2002) "A class contains a
description of data ("state")
> stored in the objects of the class.

With what does the class describe the data or state? With variables corresponding to other classes, or only other "types", or both?

I'm not exactly arguing here, just trying to clarify. Pierce's definitions, while not necessarily incorrect (jury's still out), are novel in comparison with most of my other sources of type theory (e.g. Cardelli, Date).

> A class implements its interfaces

For which we have no definition - is an interface a type, or does it have a type?

> by specifying methods that describe what operations can be performed
> on the data stored in the objects of the class.

So a class is a variable specifier - it puts constraints on the value transitions which variables declared to be of its class can assume?

> A class also describes a set of invariants that are preserved by every
method in the class.

A very important concept, agreed. But this assumes mutability, and thus we're talking about variables rather than types. Date distinguishes these concepts nicely in The Third Manifesto, and even in Intro to DB Systems.

> An invariant is a constraint on the state of an object that should be
satisfied by every object of the class.
> The main purpose of the invariants is to establish what objects belong to
the class.

So it's set membership, like membership in a type?

> An invariant is what distinguishes datatypes and classes from each other.
"

But you're talking about invariants across state transitions, whereas type implies set membership.

> As I said before, the purpose of a type is to highlight differences
(absences of behavior) whereas a
> class hierarchy is intended to highlight similarities (invariants).

Hmmm. Sounds an awful lot like types and relations - relations (actually relation variables) establish invariants (constraints) on their member tuples (and subsets of tuples), which are composed of values from types. I'm NOT equating classes and relations - just observing that they step on each others' conceptual toes. I think relations offer a much stronger mechanism for enforcing constraints, but that's just my opinion - I've seen too many OO systems where code reuse was the primary motivator, and subclasses didn't give a crap about their superclasses' invariants / contracts.

• Eric