Re: Object Class and Data Type

While I don't doubt the authority and expertise of the source authored by Dr. Pierce that you present, I need to obtain and read it further. I appreciate the reference though. In the meantime, I must rely on my own observations concerning the distinction.

I don't find the arguement convincing and I find it somewhat bothersome. By your argument, any abstract or user-defined type is created to highlight differences in behavior (a la "type"). A class, on the other hand, is not a type, and is only defined in terms of some hierarchy system, designed to highlight similarities across types. This would imply that a class is incapable of existing by itself, outside of some type system upon which to draw from and build upon (from another previously specified class) - entirely hierarchical by your account. Of course, this seems to implicitly discount or even ignore multiple inheritance and lattice typing systems and a variety of other issues.

"Tom Hester" <$$tom_at_metadata.com> wrote in message news:a8b99$406a148a$45033832$30830_at_msgid.meganewsservers.com...
>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)

He also writes: "A type system is a syntactic method for enforcing levels of abstraction in programs." This makes a lot more sense if you want to draw the distinction between class and [data] type.

>"A class contains a description of data ("state") stored in the objects of
the class.

The same can be said for data types, even built-in types. It's just that we, as type users, don't see the internal representation or see any polymorphism that might take place. In other words, it holds fidelity to encapsulation, unlike most designers/users of classes. Though there might not be a programmatic tie-in to inheritance at the programmer level concerning built-in types as of yet, it doesn't discount the fact that fidelity to common operations across different types is both recognized from a modeling perspective and enforced at implementation (yes, the same thing as an invariant).

A class implements its interfaces by specifying methods
> that describe what operations can be performed on the data stored in the
objects of the class. A class also describes a set of invariants
> that are preserved by every method in the class.

As does a [abstract] type specification. Or are you arguing in terms of data structures with an explicit lack of behavior?

>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.

Data types also depend on invariants in the same way. Both depend on invariants to specify an allowable set of values and operations and perhaps state transitions. One might be defined and described programmatically while the other is modeled and specified in design but without necessarily using a unifying programmatic definition construct.

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

If Dr. Pierce truly wrote this, I'm shocked. I find it specious, unless the entire quote is taken out of context.

Before the word 'class' came along, abstract data type was the term of choice. Perhaps we are talking about two different things. Does your use of the term, data type, include the use of abstract data types? Perhaps you are drawing a distinction between type constrained to primitives in the 3GL sense versus the concept of abstract types?

> 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).

Actually you wrote: "a set of data types is intended to elaborate the differences between sets of values." Which is it? Nonetheless, I find the distinction arbitrary. Both similarities and differences exist across either, whether we call them types or classes, and across the dimensions of state, behavior, and integrity. If one wants to draw the distinction that a class is viewed from one perspective (generalization) and a type (distinction) has another, fine. But in the end, a duck is a duck and the intentions a virtually the same - defined allowable states and behaviors.

• Dan

"D Guntermann" <guntermann_at_hotmail.com> wrote in message news:HvEx8L.9tC_at_news.boeing.com...
>
> "Tom Hester" <$$tom_at_metadata.com> wrote in message
> news:d2b19$406990ec$45033832$24651_at_msgid.meganewsservers.com...
> > Of course you are right. The purpose of class and type are entirely
> > different. A class hierarchy is intended to relate entities based on
> common
> > behavior; however, a set of data types is intended to elaborate the
> > differences between sets of values.
>
> So I guess real numbers, rational numbers, and integers are not part of
the
> same class hierarchy since they are data *types* versus your precious
> classes. What kind of reasoning is this? There are still basic
properties
> of numbers shared, whether its called class or type.
>
> Isn't the set of engineer objects in some context a subset of person
> objects? The set of values are different based on semantics and rules,
but
> they are drawn from the same generalized set - the same as numbers.
>
>
> So, for example, it is common for a
> > class hierarchy to have a single root; often called object or entity.
But
> > data types rarely if ever inherit from a single basic data type.
> > Furthermore, class itself is typically defined as an object with certain
> > behaviors. On the other hand, one never sees data type, a base type,
> > defined as a data type!
>
> You are getting data type and built-in data type confused. You are also
> confusing low-level constructs with higher levels of abstraction.
>
> - Dan
> >
> > "Laconic2" <laconic2_at_comcast.net> wrote in message
> > news:0fudnaF9l9x-kvXdRVn-uQ_at_comcast.com...
> > > Over in the OTLT thread, I saw where someone used the name "CLASS" to
> > > describe the code_type. It seems to me that many people use "class"
and
> > > "type" as though they were synonyms. It seems to me that they are
not.
> > >
> > > Any thoughts?
> > >
> > >
> > >
> > >
> >
> >
>
>
Received on Wed Mar 31 2004 - 10:40:12 CEST