Re: Then why...?

[lynch@aristotle.ils.nwu.edu (Richard Lynch)]

>
>I'm not sure that I understand why several of you want to move to 2.0, but
>not to CLOS.  Perhaps you could be clearer about what it is that you *do*
>want and expect to find in 2.0?  If what you've got works (as we find
>version 1.3.2 does) why not stick with it?
>
>Blake Meike
>blakem@world.std.com
>
>
0.  We are quite happy to move to CLOS.  We just want the transition to not
be sheer hell.  We want the code we have written to be either still usable
for one or two versions or at least easily converted.  Asking for upward
compatibility in software is really not too unusual.  Though I am happy to
admit that it might be particularly difficult or even impossible in this
situation.

1.  CLOS is a far more widely used standard than Object LISP.  It is a
standard described in _Common_LISP_Object_System_Specification_, X3J13
Document 88-002R, June 1988, Bobrow et al.  This committee is widely
regarded as THE source of specifications for LISP and LISP extensions. 
Object LISP, as far as I know, is specific to MACL (I can find no
references to it's existence anywhere but MACL manual).

2.  CLOS offers a large variety of features that are not available in
Object LISP:
    A.  It also makes a distinction between classes of objects and
instances of objects, which IN SOME CASES can produce more efficient code. 
[Specifically, when the methods are complex, the classes are few, the
instances are many, and the data on instances is small.]
    B.  It provides before and after methods.
    C.  There are various slot options which are just not available in
Object LISP, such as :allocation.

[The above are NOT meant to be completely derisive of Object LISP.  Object
LISP DOES have some advantages over CLOS, and it HAS been very nice to work
with for the most part.]
[I am NOT a CLOS expert (yet).  Any mistakes or ommissions above are
entirely my fault.]

3.  1.3.2 works...but there will be some serious improvements in 2.0
unrelated to CLOS:
    A.  I believe the disk I/O is going to be significantly faster, which
is rather important to me now as we have data files of around 300K...and
these are considered SMALL in terms of what we anticipate in the future.
    B.  Will be System 7.0 compatible, which means more than 8mb RAM.  Real
critical right now since our data library is growing at a fantastic rate,
and I'd rather not do my own memory paging, although I probably should (and
may have to) someday.

4.  Unless Apple behaves very strangely, 1.3.2 will not be "supported" any
longer once 2.0 comes out.  This is as it should be, but makes staying with
1.3.2 a rather unattractive option.

"TANSTAAFL" Rich lynch@aristotle.ils.nwu.edu