[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Various Topics Discussed Last Week
- To: "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Subject: Re: Various Topics Discussed Last Week
- From: kempf%hplabsz@hplabs.HP.COM
- Date: Mon, 28 Sep 87 17:11:49 MST
- Cc: firstname.lastname@example.org
- In-reply-to: Your message of Mon, 28 Sep 87 13:07:00 -0400. <870928130706.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
> One way out of this dilemma is to simply have the :BEFORE method and the
> :AROUND method for INITIALIZE-INSTANCE be reserved for the system.
> Similarly for the :AFTER and :AROUND methods of ALLOCATE-INSTANCE.
> This would leave no places where user defined hooks could be inserted before the
> INITIALIZE-INSTANCE primary is run. 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 don't see how the methods could be reserved, since there isn't just one;
> there's one for every class. However, your proposal is essntially the same
> as my proposal to have a specialized kind of method combination for these
> generic functions, so that user-defined methods would naturally go only where
> they made sense. For some reason that proposal provoked a lot of opposition,
> so I dropped it. It could be revived if there is renewed interest. In the
> meantime, I won't try to put anything about this into the draft object
> creation proposal.
They are reserved in the same way that the symbol INITIALIZE-INSTANCE
is reserved for a particular generic function which has system defined
methods that you redefine at your own risk. I think what I meant is
that the qualified methods are defined by the system for use in
implementation dependent ways, in the same way a default
INITIALIZE-INSTANCE method is provided. I don't think that
INITIALIZE-INSTANCE needs to be signalled out with a special kind of
However, if there's strong opposition to this, then maybe an addition to the
paragraph in the initialization concepts section which begins "Note:
nothing is guaranteed about ...." along the lines of "Users are encouraged
to redefine the INITIALIZE-INSTANCE primary if they want to modify slot
initialization, rather than using a :BEFORE qualifed method, since the default
INITIALIZE-INSTANCE method will always modify the slots if required by
the -initarg-list-, regardless of the initial state of the slots." This would
at least warn users that :BEFORE method combination won't work as they may
think in this case.