Comment on CLOS

[Masayuki Ida <ida%aoyama.cc.aoyama.junet@UTOKYO-RELAY.CSNET>]

I got a mail which is attached at the bottom from Mr. Ohkubo
who is chairing the subcommitte for OOPS under my Jeida
Common Lisp Committee.

My personal opinion is not included here.
But, I feel several of them are agreeable.
I will send my comment in a separate mail.

PLEASE INCLUDE MY NAME IN THE LIST AS "IDA%AOYAMA.JUNET@RELAY.CS.NET".

Thank you.

Masayuki Ida
-------------------------- The mail I got --------------------------------

From ohkubo@pfrad.pf.fujitsu.junet Thu Apr 14 15:32:01 1988
Date: Wed, 13 Apr 88 17:05:24 JST
Subject: Please forward this mail to CLOS mailing-list

Dear Prof. Ida,

Please forward this mail to CLOS mailing-list.

Thanks in advance.

	ohkubo

-------------------------------------------------------------------------------

Here are some questions and problems about the CLOS draft. I hope this
will help to refine the CLOS specification.

			--- ohkubo
			(ohkubo%pfrad.pf.fujitsu.junet@uunet.uu.NET)


1. About the error signaled when next method doesn't exit.

    The CLOS spec intends the user should check whether the next method exits
    by next-method-p, but it will degrade the modularity, because the user
    should concern about his method might have a method with the same name
    which discriminate on the super class or combined with method combination.
    In the system where multiple inheritance is supported, next method of 
    some method doesn't mean one unique method. There is a case where same
    method have a next method in on case, and there isn't next method in another
    case, depending on the context. (On the other hand, in Smalltalk 'super'
    method can be decided statically). The method combination facility further
    complicates the decision whether next method might be exit. This might
    enforce the user should always use next-method-p.

    To solve this problem, Object System should call a generic function named
    such as 'no-next-method', when call-next-method is invoked but there isn't
    such method, and the default method of 'no-next-method' should signal an
    error. With this modification user can write 'no-next-method' which does
    nothing or invokes error notifier. This mechanism is the same as
    'no-applicable-method'.

2. Who and when remove a method defined on 'update-instance-structure'?

    Updating instances with class redefinition is important, but the procedure
    should be existed temporarily while only updating. With the current
    specification, the method defined on 'update-instance-structure' will
    become a garbage who will never be called again. Because the class specified
    at its parameter-specializer is obsolete after redefining the class, but the
    method will last until someone removes it. If user intends to remove the
    'obsolete method', he can't have a confidence that the method is obsolete
    and never be used agained. Because some implementation might postpone
    updating instance until the object will actually be used.

    My proposal with this problem, see 3.

3. CLOS doesn't support updating a slot structure.

    Update-instance-structure gives chance to revise an instance structure while
    redefining class, but it can't be used to revise a slot strucure. For
    example, some slot now holding a list and the user find it can be an array
    and want to convert slot structure of the existing instances for compacting
    memory. In this case, class definition itself need not be changed, so 
    updating-instance-strucure doesn't be called. If the user redefines the
    class with the same class description intentionally, update-instance-
    structure can't get proper arguments, because slot name remaines unchanged.

    To solve the problems stated at 2 and 3, CLOS should include 'all-instances'
    with the same function as 'allInstances' of Smalltalk. I know this is
    very difficult for some implementation. But 'all-instances' is very
    convenient while maintaining objects in virtual image. It will not be 
    appropriate to demand 'all-instances' be implemented fast enough as other
    lisp functions.
 
4. CLOS doesn't specify what will be happen when defining an ordinary function
   or a macro which has the same name with the existing generic function.

5. When defining a generic function having the same name with the preexisting
   ordinary function, current spec says it is error. Is it a proper definition?
   In contrast to the case of defgeneric or defmethod, add-method includes the
   ordinary function as a default method. What is this rationale?  Might it be
   rather proper to retain consistency?

6. 'delete-class' and 'delete-generic-function' should be defined.

    It isn't easy and isn't clear to delete a class or a generic function as the
    case of deleting a structure or a function for the user. It also depends
    heavily on each implementation. CLOS should define user interface to
    delete a class and a generic function, and also provide sufficient mechanism
    for the programmer writing a programming environment.

7. Will it properly work when there are methods with the parameter specializers
   whose meta classes are different in one generic function?

8. Introducing private slot.

    In classical object systems such as Smalltalk or Flavors, there are methods
    they have special semantics for a particular class. This is implied by each
    method is belonged to some class. In the methods defined on this class or
    its subclasses, instance variables defined in this class are freely
    accessible. This makes it possible some slot, which only accessible in some
    group of methods, doesn't need to define an accessor. But in CLOS, there
    isn't a class which have special semantics for a method. CLOS should provide
    the mechanism which allows to access a slot only in some group of methods.
    In the current spec, someone want to read a slot and define reader then all
    the people can read it.

9. At the first line of page 1-35 in CLOS draft, "Declaring Method Combination" 
   might be better than "Declarative Method Combinarion". Declarative method
   combination means for some reader the demon method such as :before and :after
   method, and procedural method combination means 'super', 'run-super', or
   'call-next-method'.
-------------------------------------------------------------------------------