HLL/INT: What is an object, anyway?

[Jecel Mattos de Assumpcao Jr.]

On Fri, 9 Jun 1995 14:09:55 -0700 (PDT),
"'Chris Harris' B. Harris" <chharris@u.washington.edu> wrote:
> In the past, we've had two very distinct versions of an "object".  First was
> Mike's old cells proposal, which provided a pretty solid framework for
> low-level objects (or cells, if you prefer), but seemed pretty far from what
> we eventually wanted with the HLL, etc..  Not that he meant it to be used in
> the HLL, of course.  Just that we never got around to briding the two....

There were several separate ideas: cells, toolboxes, etc...

I see no reason why they couldn't be refined into something that was
integrated with the HLL. But we didn't seem to be moving in that direction.

> Second is the definition of "object" found in the TUNES glossary: "A unified
> concept to manipulate computer abstractions".  In other sections, it goes
> into more depth about how unified implies that this concept should be simple,
> universal, and how much of TUNES' power will come from this.

Right.

> Now this second definition is cool; it sounds a lot like what TUNES is
> looking for.  But it still doesn't answer my question of what an object is.
> As nice as theory is, it remains true that we must eventually come down to
> something that can be expressed, through various abstraction levels, into
> native machine code (or perhaps C in the case of the OTOP project).  So what
> can we can an object?  Seems we can't have much of an "object oriented" OS
> without answering this question.

Yes - there must be a link between the philosophical definition of an
object and the implementation oriented one.

I'll paraphrase Mario Tokoro's ( philosophical ) definition of objects:

   1 - it has a unique ID
   2 - it devides the system into the outside and the inside parts: it
       has a well defined *interface* between these parts

To get a concurrent object, he adds:

   3 - it has computing power

The second part of the definition implies that an object has a private
memory. The exact details of these three items are what set the various
object models apart from each other.

Looking at 2, we see that an object normally looks very different on
the outside and in the inside. It can be very abstract and based in
message passing in one case, and have a very common procedural look
in the second. One thing that attracts me about Self is just how OO
the objects are on the inside as well.

When we try to come up with an implementation oriented definition, we
see that 2 has something missing. It is hard to define the inside of
the object in a complete way. That is why we add a kernel, or a
Virtual Machine or something like that. It might be something as
simple as some compile time tricks and a runtime Vtable like in C++,
but there is always something more than meets the eye when looking
inside the objects. I have decided to make this explicit in Merlin
by say that "an object divides the system into an outside, an inside
and a deeper inside". There are now *two* interfaces. The new one,
between the object inside and the deep inside, I call the "reflective
interface".

> Of particular interest to me at the moment is how "OO" (in the modern
> computing world definition) low-level (or high-level -- is there a
> difference?) TUNES objects will be.  Having no kernel, it would seem
> difficult to support inheritance and other rather complex OO features
> without help from the objects themselves.  This is cool, but what if we
> wanted to have standard, system-wide inheritance or something?  Is this
> something TUNES will be able to do?  Can we design intelligent
> UI/database/math/whatever libraries without this, or some other good
> organizational scheme?

Inheritance could be defined by an "inheritance object", for example.
For it to be system-wide, you would just have to make sure that everyone
shared the same inheritance object. If anyone ever wanted to have a
different inheritance, nothing would prevent them. So it looks like
we are defining some kind of "kernel", but that is not really the case.
All objects might share some system object, but they would do it because
they want to, not because that is a design limitation.

> Any thoughts to share?  I'd like to get with my "job" and start helping with
> the UI and/or HLL syntax.  But I'm hard pressed to know where to begin either
> of those until the HLL semantics are fleshed out a good deal more....

It is a very hard job! You are right that knowing "why" we are doing
things is the first step before worrying "how" we will be doing them.
In fact, I wrote an article called "Why objects?" in 1983 where I gave
three reasons why OOP was important ( I'll make a translation available
in my next release of my www pages ). Another important reason was given
by Alan Kay:

  All complex systems are built from a collection of smalled componentes.
Why divide a computer system into weaker things like procedures and
data structures? Why not divide the computer into hundreds of small,
specialized computers - make each part as powerful as the whole!

-- Jecel