[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Various Topics Discussed Last Week
- To: Common-Lisp-Object-System@SAIL.STANFORD.EDU
- Subject: Re: Various Topics Discussed Last Week
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Mon, 28 Sep 87 21:01 EDT
- In-reply-to: <870928-164145-1052@Xerox>
Date: 28 Sep 87 16:41 PDT
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
JAK This makes :BEFORE methods on INITIALIZE-INSTANCE less then
It is easy for a :BEFORE method to get around this
by simply side-effecting the initarg list
I don't think we have said that this is either possible or legal.
In fact since the initarg list is received by the :BEFORE method
for INITIALIZE-INSTANCE as an &rest arg list (if received at all;
the method might have only &key parameters and no &rest parameter),
I believe it would be a violation of Common Lisp to modify it.
Once upon a time we allowed side-effecting the initarg list in
Flavors, so I have reasons to be opposed to allowing it in CLOS.
Programmers using method combination always have to take into account
the contract of methods they are combined with, or possibly lose.
I agree that that is true.
I don't see this as any worse than:
JAK Users redefine these qualified methods
at their own peril, as is the case with redefining any system
defined method (or function for that matter).
I guess the upshot is that I am not uphappy for users using :BEFORE
methods, since they can achieve the results they want easily, and can
know the effect of their programs.
I still think that by allowing :BEFORE methods on INITIALIZE-INSTANCE we
are creating an attractive nuisance. Perhaps the good effects of using
standard method combination instead of introducing something special
outweigh the bad effects of occasionally trapping a user into trying to
write code that won't work, but it's something to think about.