The GEOS way of object-orientation is what I consider to be the purest form
of OOness. It literally sends messages, not necessarily making function
calls. To send a message, the kernel puts the message on a thread's queue,
where it sits until the message can be processed by the intended recipient
running in that thread. You can also call, which means the message will be
sent and processed immediately (actually, the caller will sleep until the
recipient has processed all waiting messages and the called message). There
are many automatic processes that occur, two of them being the "constructor"
and "destructor", which you can intercept and add code to. You intercept
messages by subclassing them, then writing your code to handle the message.
You'll normally do an @callsuper() to make sure the superclass does it's
part.
When an object is receiving a message, the block the object instance data is
stored in (and the block containing the method code) are both locked down
automatically. The method then processes the message, then the blocks are
unlocked. It might sound inefficient, but it is the best way to allow the
memory manager to make memory available to other apps.
There is no multiple inheritance in GEOS. You can't have loops in either your
class hierarchies or object trees. Object trees are the structures that hold
the objects in your program. For instance, the application will have a
GenApplication object. This is the object that the system will communicate
through when it talks to your app. Under the GenApplication comes the
GenPrimary (usually) which is a "child" of the GenApplication. The GenPrimary
is the main window of the app, and is the parent of your menus and dialogs,
which are GenInteraction objects. When classed messages are sent to the
application object, they trickle down until the object of the correct class
is found, then the message is processed. If your subclass you created doesn't
handle that message, it will go to the superclass, and the next superclass,
and so on up the class tree until it finds the class that handles it. If it
doesn't find a message handler, the message simply disappears and is not
handled. This is not a problem and happens all the 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.
>>>>>
Yes, you're very right. GEOS will have at most 3500 handles, usually 2500. I
would recommend using a HugeArray. It's a nice data structure that uses VM
files to store the information. It can grow to just about any size.
<<<<<
3. Does GOC have dynamic binding, that is, can I send a message to an object
without knowing what the class is?
>>>>>
Sure, you can dynamically create messages (and dynamically create objects)
and send those messages to any object you want. As I mentioned above, the
message will simply disappear if the recipient object cannot handle the
message.
<<<<<
4. What sort of utility general storage classes are there available?
Extendable arrays? Keyed arrays? BSP trees?
>>>>>
None come to mind. You can always subclass MetaClass and create your own data
structures using that. In fact, rather than using global variables some
engineers will store data in a Meta object. Thus the size of the app's fixed
block is kept small and the memory manager will be happy.
<<<<
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 information, no matter what it is (class structures, objects, code of any
kind) is stored in memory blocks. VM files are made up of basically memory
blocks. To tell the VM manager to save a block, simply mark the block
"dirty". The block will then be saved at some time in the future. If the VM
manager is told that there are objects in the block, the relocatable instance
data will be automatically unrelocated/relocated during saving/loading.
<<<<<
6. Does anyone know where I can find either a GOC programming tutorial, some
example code, or preferably both on the net?
>>>>>
Yes, my web site has several applications complete with source code. Note
that some of the source code does not meet all of Geoworks coding conventions
at this time. I will rewrite them to do so as time allows.
Nathan