> 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.
In the interest of getting another language for GEOS......
> 1. What's the object-oriented programming paradigm in GOC like? For example,
> does it have automatic constructors and destructors? I imagine that every
> 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?
I'm told its nearest relative is Objective C, but I can't verify that. It has
nothing that resembles an automatic constructor or destructor.
Message calls (two types: @call and @send, the first blocks the calling routine
until the method returns) are fairly expensive. Each requires a handle; you
can tell that you've got an unterminated recursion or a sorcerer's-apprentice
problem when you run out of handles...
GOC encourages the use of plain old structs for data-only objects.
>
> 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.
By using Local Memory. Almost everything does. Lmem divides memory into 'blocks'
(which need a system handle), and then subdivides the blocks into 'chunks' (which
have a local handle table in the block) You then reference the chunks using an
'optr', which is a combination of block handle and chunk handle.
MemAlloc is a Bad Thing - it creates a fixes block of memory, rather than virtual
memory. Very antisocial, and a good way to run out of memory. Avoid.
> 3. Does GOC have dynamic binding, that is, can I send a message to an object
> without knowing what the class is?
Yes. In fact (correct me if I'm wrong, please!) _all_ messages are stored in the
same table. If an object doesn't recognise a message, it uses a default null method.
Unfortunately, this means that each object's messages have to have standardized
unique names like MSG_VIS_TEXT_GET_ALL_VM_BLOCK.
> 4. What sort of utility general storage classes are there available?
> Extendable arrays? Keyed arrays? BSP trees?
Unarranged LMem and the general-purpose Database library. (I think I'm forgetting
some...)
> 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*?
First, no pointers will survive the process. Neither will block handles. But
chunk handles will. The upper half of an optr (the block handle) has to be
reconstructed when the VM file is attached.
> 6. Does anyone know where I can find either a GOC programming tutorial, some
> example code, or preferably both on the net?
No tutorials that I know of. I posted the source code to the last beta of RenoComm
(my project) to comp.binaries.geos, and there's a copy at
http://www.cs.tu-berlin.de/~pilz
- ------------------------------------------------------------------------------
"Why do your people always ask if someone is reno@smart.net
ready right before you do something massively unwise?"
- Delenn, Babylon 5/War Without End by J. Michael Straczynski O-