Reinitialization

[Gregor.pa@Xerox.COM]

    Date: 06 Apr 88 10:43 PDT
    From: Dick Gabriel <RPG@SAIL.Stanford.EDU>

    I agree with Gregor's analysis and with the general outline
    of his solution. However, I usually have bad reactions to
    the use of flags to signify flow of control, so I would prefer
    to have some other means of implementing the solution.

I think the solution you propose doesn't address one of the problems we
were trying to address.  Looking back over our message, it seems we
didn't make that goal clear at all.  This message tries to show why we
decided to use a flag to communicate the caller of shared-initialize.

Moon may also want to comment on this since his message originally
suggested the use of this kind of flag.

The basic idea is that while it might be nice in practise so separate
out the code into the part which is specific to each of the three
pseudo-initialization functions and the part which is common, this kind
of separation may be difficult to do in practise.  For this reason it is
convenient to have the shared code know who its caller was.  That way
the shared code can make decisions about what to do based on who its
caller is.

As you point out this can be done by passing in a function which will be
called, but this just reduces it to having to separate any code which is
partly shared and partly initializer-specific.  The intuition is that
this would prove to be a pain in practise.

    Each of the update functions would take an extra argument, which
    is the initializer function. The code that invokes the updaters would
    pass in the current function binding for shared-initialize. If a user
    wanted to alter the shared initialization behavior he would define
    a method on shared-initialize, as in Gregor's scheme.

    If he wanted to define radical new update behavior, he would define
    methods on initialize-instance, reinitialize-instance,
    update-instance-structure, or class-changed, as in Gregor's scheme.

As I mentioned, the problem isn't when you want to define radically new
behavior its when you want to define behavior which is a complex blend,

    Suppose he wanted to change the initialization behavior for, let's
    say, reinitialize-instance. In Gregor's scheme he would write a method
    on shared-initialize which discriminated on the identity of the second
    argument. In my proposal he would write a method on
    reinitialize-instance and supply a new initializer function:

I never intended for anyone to write methods which discriminated on the
identity of the caller argument.  I would certainly think it was a bad
idea to do that.  My idea was that the caller argument would be used as
a flag inside the method itself.
-------