Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.c++,comp.lang.misc
Path: cantaloupe.srv.cs.cmu.edu!rochester!cornellcs!newsstand.cit.cornell.edu!news.kei.com!newsfeed.internetmci.com!in2.uu.net!mdisea!mothost!schbbs!news
From: shang@corp.mot.com (David L. Shang)
Subject: Re: Types, types: static vs. dynamic -- classification
Reply-To: shang@corp.mot.com
Organization: MOTOROLA 
Date: Tue, 28 Nov 1995 15:30:28 GMT
Message-ID: <1995Nov28.153028.20561@schbbs.mot.com>
References: <yf3rayupzar.fsf@sabi.demon.co.uk>
Sender: news@schbbs.mot.com (SCHBBS News Account)
Nntp-Posting-Host: 129.188.128.126
Lines: 70
Xref: glinda.oz.cs.cmu.edu comp.object:41520 comp.lang.smalltalk:31156 comp.lang.c++:162196 comp.lang.misc:24008

In article <yf3rayupzar.fsf@sabi.demon.co.uk> piercarl@sabi.demon.co.uk  
(Piercarlo Grandi) writes:
> >>> On Wed, 22 Nov 1995 15:21:11 GMT, shang@corp.mot.com (David
> >>> L. Shang) said:
> 
> David> Value is the state of an object. If type is a first class object,
> David> a type also has values. It is the state of the type.
> 
> >>> In article <vwjd9aje6nz.fsf@osfb.aber.ac.uk> pcg@aber.ac.uk
> >>> (Piercarlo Grandi) writes:
> 
> pcg> A quibble: if "value" is the state of an object, what is in an
> pcg> object that is not "value", _in a non prototype-based OO language_
> pcg> ? :-)
> 
> >>> On Mon, 27 Nov 1995 16:18:54 GMT, shang@corp.mot.com (David
> >>> L. Shang) said:
> 
> David> Functionality or behavior, which is the property belonging to a
> David> group of objects (a singleton is a specific case), and defined by
> David> their type.  However, the state of objects are individually
> David> different.
> 
> Uhm, sorry the quibble was a bit of a loaded question. Your answer is
> not quite the correct one, for the correct one is "the type/class tag of
> the object", but that must be intended to be part of the object's state
> _as well_ (then implementations may or many not have it as a contiguous
> part, for example those based on OTs usually don't).
> 
> "Functionality or behaviour, which is the property [of] belonging to a
> group of objects" is an abtract concept, and cannot quite be part of an
> object. This abstration is indeed represented as a some sort of type
> tag, but they are on different levels of discourse.
> 

Functionality or behaviour, though abstracted in type, it should
belongs to object, not to type.

Let T be the type, X be the object, and F be the behavior, we use
X.F to get F, not T.F. Therefore, F is not a state of T, but a
state of X.

Yes, it is a state of an object. You can say F is a value -- depends
on the language you chose -- as long as X.F can pass as a value.

To be precise, F defined in T is a type, a nested type (class).
X.F() creates an component object within X. If F is a function,
behavior, or thread, the component object is an activity. And the
activity object is destroyed when its duty is done. But F is not
necessarily a function. It could be a class for component objects
(e.g. child windows). This way, we unified the concept of nested
classes and member functions. The class concept is generalized; so
that we can build up various models such as mutithread task,
distributed server with remote services, database with transations,
etc. Transframe has this unification and the nested level is
unlimited.

I don't like the idea to treat "tags" as a part of the object.
Tags are bound to polymorphic variables only, not to objects.
C++ uses a tag as a part of the object. As a result, C++ cannot
separate the tags from object codes. That is why C++ cannot
provide a complete type info for all types.

David Shang






