Are you still there?

[Dennis Marer]

Hi Fare',


     Just now getting a chance to read what you wrote....

> (Fare->Dennis #9, 26/1/93)

>  Well, my main problem is up to now I worked in french, and all my notes were
> in french. So now, here is part of it translated (my ARJfied notes are 200Kb
> long).
>  Here are some features I expect the system to run at high logical level
> (standard language programming), and that the compiler and/or the kernel should
> support:



> * Objects are contained in Object Zones (OZ's); the simplest (logical) OZ is
> a set, which can be physically implemented by, say, a bitmap, or a list, etc.
> A more general OZ does not contain only objects, but also attributes of these
> objects (which depend in nature of the OZ and of the objects): for example, a
> room in a CAD program may contain objects, which each have its intrinsic shape;
> but each object has its position in the room for attribute.

Please elaborate on this idea!  I need more details to understand exactly how
this might work, what it will be used for, and so on.  I think I understand,
but I'm not sure - maybe some examples will help.

> * standard attributes are printing/showing format (for example, for an integer,
> the base hexadecimal, decimal, octal, binary, n-ary, etc; for a complex
> structure involving many types of number, ...); other common attributes are
> names, debug info, comments, translation into different languages, etc.

I like this idea, but I think it would be more efficient to implement these
as standard METHODS instead of standard ATTRIBUTES.  A method only adds an
entry to the virtual method table of an object, where an attribute would
add to every instance of that object.  Of course, the object would then be
able to choose whether or not it wishes to implement these methods.

By different languages, do you mean spoken or computer languages?

> * Existence range or compute range of any object is arbitrary: any object can
> be defined relatively to any other; it can be computed at any arbitrary time
> (preprocessing, compile, interpret, run, more than one object in parallel or
> in sequence at one time, etc).

Interesting idea...I wish you could expand more on this idea also so I can
better understand it.

> * There is a virtual reference constructor which takes a pointer and returns
> the pointed object. If the pointer is in a constant variable, you have a
> virtual equivalent of physical C++ x& 's.

Does this mean to actually duplicate the object being pointed to?  If so, I
agree, this is important.  Each object would need to implement its own.

> * There is a virtual pointer class, and thus virtual reference with virtual
> pointers. You can by this mean address logically any type of variable anywhere
> in the computer, etc, without changing your source program (but a big change
> in a variable's nature may cause big change in optimised object code). There
> may be a virtual type of pointer where the data isn't really read and written,
> but given as parameter to look and modify procedures. The fact that what you
> read isn't what you wrote is similar to the fact a variable may be shared
> between procedures. (practical example: ln -s = symbolic link under u*ix).

Please elaborate on this one also - it sounds similar to what I've proposed
below....


> * There is the standard recursive question in OO environment:the class class's
> class is the class class (itself), unless it is only a subclass of class.
> Well, doesn't matter if the Kernel is well written.

And of course it will be!


I hope I have not misunderstood any of your ideas - let me know if I have.
Also, I'd like to hear more of these ideas - it sounds as if we are thinking
along similar lines!


I've been thinking about the more general sense as to what objects there would
be in this system.  At the very top, the 'object' class would provide a base
class for all objects (an imlpied ancestor when none is specified) which
would describe virtual functions for displaying, copying, writing to disk,
reading from disk, and so on.  It contains no attributes (data).  A direct
descendant from this would be the 'task' object, defining a program, its
starting point, and so on.  The 'task' object also defines how a program is
loaded.  Descendant from the 'task' would be the 'device' object, which is
used to deal with all devices, physical or logical.  For example, a disk
drive is a descendant from the 'device' object; and IDE disk drive is a
descendant of the disk drive object, and so on.  Included in this are
kerboards, video display, disk drives, mice, and more.

Object could also be shared among processes.  The code needs only to be loaded
into memory once, and can be accessed by all processes.  Object instances are
a little more difficult, and must be dealt with by defining a 'sharedObject'
class which overrides the constructor and deals with multiple accesses.  The
concept of persistent objects (ones which may be accessed several times by the
same program) also follow this example.  At any one time, many parts of a
program (or even separate tasks) may use the same object, pointing to the same
instance of the object in memory.  Each constructs (instanciates) and destructs
the object individually, but the object does not actually get destroyed until
nobody references it anymore.

Files will be a use for persistent objects.  Many tasks may use the same file
at the same time, usually only reading from the file, needing only one copy of
the file (or one file buffer) in memory at one time.  Files will also be
memory-mapped for convenient access, being able to return a pointer as if the
file existed in a continuous chunk of memory.  This does not need a series of
reads & writes, but is accessed and written to using only pointers.  It's very
easy to implement on the 386!

Well, that's a bunch of ideas...hope to hear your input as well, and further
explanation of your ideas.  Take care, and keep in touch!

				Dennis