Newsgroups: comp.object
Date: Sat, 26 Sep 1992 17:01:30 -0400 
From: Stefan Monnier <osoelgaultier+@CMU.EDU>
Subject: Re: Implementing an OO system

Excerpts from netnews.comp.object: 26-Sep-92 Implementing an OO system
Michael O'Reilly@tartaru (3268)


> I am writing a concurrent, distributed, persistent, object oriented
> programming environment and have a few problems (surprise, surprise. :).
> The language used is one I made up. (Vaguely C like. I like C's
> concise syntax, and non of the OO languages around seem to have
> anything like it). The distribution is coarse grained, and
> communications are assumed to be expensive. Memory is assumed to be
> relatively cheap. CPU time assumed to be moderately expensive. (I.e.
> Would like to have a high efficiency. ). Just to make things easier,
> and more portable, the language is interpreted. The language is
> strongly typed, with the intention of static binding as many methods
> calls as possible.

Why is interpreted more portable ?

> It is OO as a fairly fine level. Integers strings etc al are classes.
> I.e. '1' is an object of class Int. etc.

> 1) Has anyone got any pointers on a good garbage collection scheme to
> use??? I am using reference counting at the moment (the distributed
> nature seems to require it. Any know any different??) 

Look in the OOPSA papers: it's really good for everything from
GC to anything related to OO.

> 2) What is a good way to handle garbage collection of class
> definitions?? The problem here is that nothing using the class isn't
> a good reason to throw it away. At some instance, there may be not
> class that actually uses the List class, but you can't throw it away!
> On the other hand, it is conceivable that during development, a number
> of superfluous classes get created.

It seems a bit confused to me: I personnally can't see in which sense
the class memory management should be different !

> 3) What is a good way to handle recursive class definitions?? (i.e.
> How would you implement it??). The class I had in mind is...

> 	class List {
> 		List next;
> 		Data d;
> 		/* various normal methods defined */
> 		}

> 	class Data {
> 		List l; /* List of data */
> 		String s; /* and some string.. */
> 		/* more methods here */
> 		}
> How does a compiler handle this sort of thing??? I have a few
> solutions in mind, but they aren't very clean.. :(

Several passes (eiffel ISE does 4 passes).
For example, you could first compile the declarations, then the
implementation !
(cause, in the declaration, there is no method calls, you only need to 
know that a Data object has pointer to a List object (the size of a pointer
is well known), you don't need any more information about List)

> 4) What is a good syntax, and/or implementation of parameterized
> classes like 
> 	class List(T) {
> 		List l;
> 		T data;
> 		/* blah blah */
> 		}
> What if you want two items of data?? Yes, you could make T a complex
> type with two elements, but would this be less efficient??

Good syntax is a question of taste.
Efficency is a question of implementation !
I don't know which is easier to implement efficiently !

> 5) Concurrency. Anyone got any pointers for coarse grained
> concurrency?? I had in mind an exclusion system like...

> 		/* code.. */
> 		{{ /* This block is exclusive per object */
> 			t = a;
> 			a = b;
> 			b = t;
> 		}}
> The gets implemented by compiling in a lock acquisition for some lock
> numbered N (where N is computed from the object handle and the
> function). The lock gets created if it doesn't exist. Problems here
> include making sure N is unique. Maybe maybe N a 64 bit number
> comprised of a 32 bit object handle, and a 32 program counter.

> Anyone got any better ideas for supporting concurrency??

This may be a bit too 'low-level'. It seems sufficient to implement
about any other known syncronisation but I would be VERYuseful
to be able to have some influence on the scheduler: the most important
thing would be a 'wait' and 'wakeup' construct (it's hard to 
avoid busy-waiting without it).
But it sure it interesting cause it is relatively simple but yet
powerful enough (the other tools would be provided as libraries:
semaphores, ....)
Another appreciated way to include synchronisation mecanisms
in a language is the monitor.
Anyway, all this also depends on how you specify the concurrency (do you use 
a fork construct, or is every object considered another process ?) !

Good luck !

	Stefan Monnier

-----------------------------------------------------
-- On the average, people seem to be acting normal --
-----------------------------------------------------





Newsgroups: comp.object