[cap-talk] "Composite", was "Same" key

[David Hopwood]

Charles Landau wrote:
> At 8:47 PM -0800 2/6/07, Mark S. Miller wrote:
> 
>>Can any of the KeyKOS crowd/community clarify what the KeyKOS
>>literature meant by "object"?
> 
[...]
> - I don't think we had a term for "the thing that a capability refers 
> to, such that different capabilities refer to different things". Here 
> I'll call that an "atomic object".
> 
> - In KeyKOS we used "object" to mean "a group of one or more related 
> atomic objects". At the time I wasn't aware of any other term for 
> this concept. I'm not even sure if object-oriented programming had 
> yet been invented back then.

Although he isn't usually credited for it, object-oriented programming
(or at least object-based programming) was arguably invented by Tony Hoare
in 1965:

Algol Bulletin 21.3.6,
C. A. R. Hoare: Record Handling, pages 39-69, July 1965.
<http://archive.computerhistory.org/resources/text/algol/ACM_Algol_bulletin/1061032/p39-hoare.pdf>


This article already uses the term "object" (a record being a
representation of an object). It was a direct influence on Simula 67:
<http://staff.um.edu.mt/jskl1/talk.html#History%2067>.
(Simula I had not supported the "prefix" mechanism that Simula 67 uses
to implement interface polymorphism.)

The term "object-oriented" were also coined at about the same time:

<http://www.purl.org/stefan_ram/pub/doc_kay_oop_en>

# > When and where was the term "object-oriented" used first?

Alan Kay:
# At Utah sometime after Nov 66 when, influenced by Sketchpad, Simula,
# the design for the ARPAnet, the Burroughs B5000, and my background in
# Biology and Mathematics, I thought of an architecture for programming.
# It was probably in 1967 when someone asked me what I was doing, and I
# said: "It's object-oriented programming".

The term "object-oriented" would not become more widely popularized until
at least Smalltalk-72. So this is about the same time as the first Gnosis
design paper (1972), but a few years before KeyKOS was working or released
<http://www.cis.upenn.edu/~KeyKOS/Key370/Key370.html>.

Incidentally, from /The Early History of Smalltalk/ (written much later):
<http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html>

# Object references were handled on the FLEX machine as a generalization of
# B5000 descriptors. Instead of a few formats for referencing numbers, arrays,
# and procedures, a FLEX descriptor contained two pointers: the first to the
# "master" of the object, and the second to the object instances (later we
# realized that we should put the master pointer in the instance to save space).

[...]
# That fall [of 1969], I heard a wonderful talk by Butler Lampson about CAL-TSS,
# a capability-based operating system that seemed very "object-oriented"
# [Lampson 69]. Unforgable pointers (a la B5000) were extended by bit-masks
# that restricted access to the object's internal operations. This confirmed
# my "objects as server" metaphor. There was also a very nice approach to
# exception handling which reminded me of the way failure was often handled
# in pattern matching systems. The only problem -- which the CAL designers
# did not see as a problem at all -- was that only certain (usually large
# and slow) things were "objects". Fast things and small things, etc., weren't.
# This needed to be fixed.

[...]
> At 1:26 AM +0000 2/11/07, David Hopwood wrote:
> 
>>OTOH,  it's quite possible that someone will come up with other objections to
>>"abstraction".
> 
> I happen to think that "abstraction" is too broad. I can mean a lot 
> of things that are not objects.

It can, and I initially had some reservations on that basis, but as I said in
the previous post:

 - if it is necessary to distinguish this from some other kind of abstraction,
   then we can use "object abstraction" to disambiguate. In practice, most
   software abstractions in an object capability system will be object
   abstractions. So I no longer think that the term "abstraction" is too
   general.

>>The particular choice of terms is, IMHO, far less important than the principle
>>that the same term should not be used to refer to several distinct concepts in
>>the same subject domain. That's why I object [...] so strongly to the suggestions
>>to use "object" for *both* of the concepts that MarkM's thesis calls "objects"
>>and "composites".
> 
> So may I humbly suggest that until we come to agreement, we at least 
> use the term "atomic object" for the concept that MarkM's thesis 
> calls "object"?

Why would we do that, rather than just making a decision now? We seem to be agreed
on what the concepts are, so it's just a matter of deciding between:

1. Object          Composite
2. Object          Abstraction
3. Atomic object   Object

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>