Ker,OOOOOOOOO far21

[Francois-Rene Rideau]

-- (a) -----------------------------------------------------------
Let me first begin with a reply to Michael, quoting Dennis' reply to him.
The end of the reply will be an introduction to MOOSE's fundamental problem.

>>> Hi!
>>> I've knocked up a sketch for a simple kernel.
>>> I've currently left out virtual memory and object support simply 
>>> because virtual memory seems to be dependant on how we do objects and
>>>  we haven't reached a consensus (or even an understanding yet!) on objects.
>> 
>> Great - we'll be looking forward to seeing that!
>> 
>> Q: Why is virtual memory considered dependant on how we do objects?  Maybe I
>>    missed that discussion...
> 
> Something Fare' said about objects being small and this conflicting with 
> the page as the smallest unit of VM/protection.
> 
> I'm not quite certain so I'm playing it safe.
> 

 Let me confirm. if EVERYTHING is gonna be objects, then we'll have huge
objects (for example, the whole system) as well as tiny objects (for example,
a boolean); so we can't allow object memory allocation done exclusively with
page alignment (which does not mean large object won't be page aligned).
 If only Large and Huge things are really going to be objects, then we're
back to UNIX and its spawns DOS and Windows; and we've gained very little
for a hard work.

>> The structure of an object needs to be clearly defined by the kernel: how it
>> stores the attributes (data) associated with an object, how polymorphism
>> affects the virtual method tables (VMT) of an object, especially in the case
>> of multiple inheritance, and so on.  Also, this definition of an object needs
>> to be useful to all languages...this is a tall order to fill!
>> 
I agree with all that, BUT with VMT: VMT are a way slow both to use objects
and to create them. I'd rather have external descriptors on objects (access
is much slower but much much more generic than with a VMT). Then, the same as
for Peter's name service, you can ask a direct link to an object's method for
frequent use, rather than call it everytime through the long method.


> I still feel uncomfortable about defining such features as polymorphism 
> at a level where they will be so hard to change -- surely there is no one
> universally used model of objects/polymorphism etc. ...

Well, again, you rise the right, deep question.
You also said in your Mar 10 "Re: PLEASE READ THIS ONE" message
(if everybody numbered messages, quoting would be quicker)

>  The part that I find is still unclear is the role of "objects" in the
> system. The rest is a fairly conventional OS -- I'm not saying this is
> bad, if it designed properly (ie. to be simple) it can (and will) be
> exactly what we want -- something that's a pleasure to write applics
> under.
>
> Most of the problems we've had have been with the role of objects.

 Yes, Michael; I'd say that's THE problem we've had. Let's say what we
think should be the role of objects in the system (and I fear that's
where we may disagree), for its the ESSENTIAL question you asked we
answered in a previous message.
 We all talked about objects, everyone having his idea about it. Now
it appears that we must clarify our mutual ideas, for if we're not
talking about the same thing, we can never agree (or even disagree !),
just talk each for himself.

------------------------------------------------------------------------

 In older manuals, objects were define as an embedding of code and data.
Now, I will rather say that code and data are different aspects of objects.
 Objects are a unifying scheme in computer science. Some call it schemes,
others call it functions, some may call it God, etc. The fact is we can
seek unity in computer programming (code and data or yin and yang aspects
of the Tao; one feeds from the other).
 This unity was broken when (micro)processors were built so complicated,
that code to handle data was as foreign to data as data to represent code
was from machine code.
 But unity was rediscovered, and may be achieved again.

 Object are everything; everything is an object. Unix tried to say that files
are everything, that everything could be done with a file; but Unix files
were thus implemented that only big objects could be efficiently represented
that way; and Unix didn't provide any code embedding with this data; and Unix
forced people to access data through strings. So that the system wasn't a
unified system.

 There came MOOSE, which raised hope among young programmers. It at last
was a unified system. But it wasn't a closed unenhanceable, unextensible
system. It provided generic polymorphic object managing: objects were
implemented through descriptors who themselves were objects. Objects had
a recursive definition, so that the only basic code/data was a convention
on how to code objects so that others are aware of it and its methods.

 Objects had basic methods:
- get object's descriptor : (if you have the object's descriptor, you have it)
- copy the object
- send a message to the object. For example a dictionary entry to add to the
object's dictionary.

 Objects descriptors came in tiny, small, medium. large, huge groups named
dictionaries.
(to be continued ...)