Re: BOS questions

[Sean.Levy@cs.cmu.edu]

[For readers of comp.object and self-interest, BOS is a prototype-based
object system that I have, er, prototyped in Tcl. It is available via
anon FTP to monch.edrc.cmu.edu under /usr0/snl/archive/bos-1.2.tar.Z
(you have to cd to /usr0/snl/archive first and then get the file, due to
CMU security hacks in ftpd). I thought that this would be of interest to
comp.object and self-interest, so I'm cross-posting/mailing --S]

Note: I play very fast and loose with the terminology of OOP to get my
point across. I appoogize if I offend any sensibilities, and will
clarify what I say if it is obfuscated by my use of terms.

Excerpts from netnews.comp.lang.tcl: 23-Apr-92 BOS questions Tim
Spurway@bcarh680.bnr (1601)

> This posting is really directed at the designers of BOS, but I
> thought that this dialouge would be of general interest, so I'm
> putting it on the net instead of e-mail.

> BOS is a prototype based object oriented system.  This is different
> from the traditional class based languages (like Smalltalk) in that
> there is no distinction between an object (ie. an instance) and it's
> class (ie. description of the object's behavior (type)).  Everything's
> an object.  Now the questions ...

> It seems that in BOS, everytime you create an object (by copying an
> existing one), you have to give it a new name.  Is this true?  If so,
> how is this name scoped (ie. is there only global objects?).  Is there
> a mechanism that allows for short-lived objects (ie. objects without
> a name that are automatically cleaned up after use)?  Can one simply
> 'reference' an object without actually giving it a name?  If not, why?

The short answer is: no. The longer answer is that objects with local
scope are targetted for the next version, and will go hand in hand with
a mechanism for using objects as types, i.e.

FooTraits defMethod something {Foo:anotherFoo} {
  Integer: i
  ...
}

The name i, which refers to an Integer object, and the Foo parameter
anotherFoo are both local to the scope of the method something. I
achieve this effect currently by doing things like:

FooTraits defMethod something {anotherFoo}  {
  set i [System gensym]
  Integer copy $i
   ...
  $i die
}

The object $i is "global" in the sense that it is accessible outside of
the scope of something, but the actual name held by $i is really only
known to something (pragmatic local scope :-). Also, anotherFoo could be
any kind of object, although something assumes (presumably) that it is
another Foo object. I view the lack of a type system in BOS as being the
root of both problems, and will address them together. Note that I am
extending the syntax of BOS with my "Integer: i" construct; to really do
a type system in BOS, I am going to have to stop using Tcl_Eval as my
interpreter for methods and write my own parser that "wraps" Tcl_Eval
(maybe: actually, I am not sure if I want to even allow arbitrary Tcl
code in methods in the next release, since this comlicates things
somewhat -- some input on this from folks would be nice).

Note that I don't WANT to impose a type system on Tcl itself -- I think
Tcl is perfectly fine as it is in this respect. The relationship between
BOS and Tcl is somewhat symbiotic, conceptually -- the fact that the
relationship of this implementation of BOS is more than symbiotic (it is
a downright dependency!) is due to the fact that I wanted to start
working with a prototype-based object system quickly.

> What about garbage collection?  Does it make sense to garbage collect
> in a system like BOS?

Yes, it does. Yes, it is coming. I think I may be taking a slightly
different approach than what has been done in other systems, but until
it is finished and the details worked out, I can't say for sure. More
later.

> In BOS, the 'inheritence' mechanism is very general.  Single and multiple
> inheritence is very easy to achieve using priorities on the objects you
> want to have searched for a given method.  As a matter of fact, dynamic
> inheritence is a very feasable possibility in this system (neat!).  What
> is a good example of how dynamic inheritence can be used?  What kinds of
> problems is it appropriate for?  How does the message lookup mechanism
> deal with objects that have the same priority?

The point in dynamic inheritance could be responded to with a whole
article. I will try to write down some things on this vis a vis my
application of BOS and post later. 

The message lookup mechanism deals with objects that have the same
priority by, effectively, tossing a coin. In this respect I have not
taken advantage of the work done by the SELF people, since experimenting
with various sorts of inheritance was not my primary concern (it is one
of theirs). In fact, my use of the system has been strictly in a
single-inheritance style!

> What's a good book on prototype based systems?

You should get The SELF Papers, by the SELF group (formerly at stanford,
now at Sun, I believe). It used to be available by anon FTP to
self.stanford.edu, I think, but I'm not sure anymore. I have them, but
am not sure if I am allowed to make them available if they are not from
some other source (legalities and such...). There is a SELF mailing
group: self-interest@self.stanford.edu. You can get on it by emailing
self-interest-request@self.stanford.edu. If SELF had been available in
source form and had been more portable a year ago, I might never had
bothered to write BOS. As it is, I'm so deeply into it, that I'm
beginning to see why maybe I want BOS and not SELF, but I'm really not
sure about that.

I'm not sure where else in the OOP literature there is information on
prototype-based systems, but in my area (Engineering Design) there are
some papers on the suitability of prototype-based systems for work in
design, vs. class-based systems. I can look up the references and email
and/or post them if you like.

> Thanks in advance.


>   Bell Northern Research
>   tims@bnr.ca
> ==  


Cheers,
			-- Sean
--
Sean Levy <snl+@cmu.edu>		   `... from intuition we can pass to
CMU Engineering Design Research Center      analysis, but not from analysis to
ndim Group                                  intuition.' --Henri Bergson
                      <--  Standard Disclaimers Apply  -->