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!in1.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: Wed, 29 Nov 1995 16:15:05 GMT
Message-ID: <1995Nov29.161505.2301@schbbs.mot.com>
References: <49gge1$m3j@news.ox.ac.uk>
Sender: news@schbbs.mot.com (SCHBBS News Account)
Nntp-Posting-Host: 129.188.128.126
Lines: 114
Xref: glinda.oz.cs.cmu.edu comp.object:41609 comp.lang.smalltalk:31239 comp.lang.c++:162444 comp.lang.misc:24018

In article <49gge1$m3j@news.ox.ac.uk> lady0065@sable.ox.ac.uk (David Hopwood)  
writes:

> In article <1995Nov28.153028.20561@schbbs.mot.com>,
> David L. Shang <shang@corp.mot.com> wrote:
> >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.
> 
> F is never a value. It can be reified as a value (for example a
> selector object in Smalltalk), which is not the same thing (you are
> confusing the programming language and the metalanguage we use to
> describe it).

In languages (Beta, Transframe) that unify the concepts of class
and function, function is a class. A memeber function is a nested
class.

In languages that handles classes as first-class objects, a class
can be a value. So that a function can be a value, and then a
member function can be a value too.

Yes, when you treat functions as values, you are programming in a
meta-level. But you are not necessary to use a metalanguage if the
programming language itself is reflective or has a meta level
abstraction.

> 
> >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.
> 
> This seems a strange way of describing things. The class of X can
> have a method which evaluates to a thread object, or class object,
> say.

This a natual concept that we are using in many many domain-specific
languages. For example:

	class Account is AtomicData
	{
		Transaction deposit(...) {...};
		Transaction withdraw(...) {...};
	};

	class NameSever is DistributedServer
	{
		RemoteService register(...) {...};
		RemoteService lookup(...) {...};
	};

	class Pharmacy is AdaTask
	{
		Entry drop_prescription(...) {...};
		Entry take_medicine(...) {...};
	};

	class FaxMachine is ActiveObject
	{
		Port recevie (...) {...};
		Port send (...) {...};
	};

	class SharedResourcePool is MultiThreadTask
	{
		Thread read (...) {...};
		Thread write (...) {...};
	};

They should not seem strange. For example, when I created a joint
account of the type Account, say A, A.deposit(..) will created a
transaction within the account. Multiple transactions may be created
at the same time for a joint account. But they are scheduled according
to the transaction protocols defined in the class of Transaction.

Note that

	Transaction deposit(...) {...};

is a simple version of

	class deposit is Transaction
	{
		enter (...)
		{
			...
		};
	};

		
in Transframe. Therefore, deposite is a subclass of Transaction,
and a nested class of Account.

Transaction is a nested class defined in AtomicData, the superclass
of Account.

It should not be difficult to understand the other listed examples.
They are all in a uniform structure similar to a normal C++ class:

	class A is B
	{
		function foo (...) {...};
		function bar (...) {...};
	};


where "foo" is actually a subclass of "function" and a nested class
of A.

No domain-specific extention is required for Transframe to get the
benefit of domain-specific programming.


David Shang
