> I'm about to start work on a final year university project. I'd really rather
> like to do it under GEOS, because I *like* GEOS and I think that it would be
> ideally suited for the project (a simple Smalltalk system, if anyone's
> interested). However, since the SDK isn't here yet, and it would help if I
> could do some program design, so I would be extremely grateful if someone
> could give me some pointers on some of the questions below.
How exciting! I briefly considered a Smalltalk port (little Smalltalk),
but decided against it on the basis of difficulty of porting memory
management.
> 1. What's the object-oriented programming paradigm in GOC like? For example,
Hmm. It's very similar to Smalltalk's, in that all messages are actually
sent to objects, never simply resolved to static function calls. One
difference is that there's two ways to send a message: @send, which
simply sends the message and continues execution, and @call, which sends
the message and waits for any results. Smalltalk, last I checked, has
only @call.
> does it have automatic constructors and destructors? I imagine that every
It has no garbage collection, but it does have messages which are sent to
each class as it's destroyed. Due to the fact that it's a persistent
operating system, it also has a message to be sent to every object as
it's being saved for shutdown.
> message call has to go through the memory manager, so it can page in the
> relevant piece of code, since there isn't an MMU. I would think that this
> would make sending messages fairly expensive. Would I be better off *not*
> using a separate class for fairly simple, frequently-accessed data values?
This is quite true, and in fact is one of the reasons that most
implementations of Smalltalk are slow.
However, for Geos you only have to page in the code if it was paged out
in the first place-- this is not usually true, and can always be prvented
by locking the object in question. You just have to remember to be
polite and never keep too many objects locked and unswappable at the same
time.
> 2. What's the best way of allocating several thousand small (i.e. less than
> fifty bytes) objects? If I use MemAlloc() for each one, or create an instance
> of a class, then I would end up using lots of handles, and the system could
> pretty well run out.
chunk handles.
> 3. Does GOC have dynamic binding, that is, can I send a message to an object
> without knowing what the class is?
Yes. ;)
> 4. What sort of utility general storage classes are there available?
> Extendable arrays? Keyed arrays? BSP trees?
There are none that I recall, although I think the HugeArray is extensible
(am I wrong?). There is a database library/object, but I have NO idea
what algorithm it uses.
> 5. When saving a VM file, I assume that you use something analogous to Unix's
> mmap() to tell the kernel what data to save. However, if you have a fairly
> complex data structure, then your objects will contain pointers or handles to
> other objects. How does the kernel know the format of your data, so it can
> store the complete data structure *and then reproduce it again*?
All taken care of by the compiler's datatypes.
> If anyone can answer some of these, I would be much obliged (it would also
> increase the chances of a GEOS Smalltalk system seeing the light of day).
I certainly hope this is possible. Smalltalk is slow, but it more than
makes up for that by its interactivity. Here's to your developing the
first interactive Geos development platform!
- -Billy
Working on the (first|second) interactive Geos development platform,
GeoForth. Forth: fast. Smalltalk: easy to use. No competition!