[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Please forward this mail to CLOS mailing-list
- Subject: Please forward this mail to CLOS mailing-list
- Date: Wed, 13 Apr 88 17:05:24 JST
Dear Prof. Ida,
Please forward this mail to CLOS mailing-list.
Thanks in advance.
Here are some questions and problems about the CLOS draft. I hope this
will help to refine the CLOS specification.
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
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
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