Re: Constructors

[Danny Bobrow <Bobrow.pa@Xerox.COM>]

Moon argues that constructors are good because they provide:

   (1) A cleaner interface for the caller

This is an argument for a functional interface that buries the name.  A
defun does that, as Moon points out.

   Some reasons to have a :CONSTRUCTOR option in
   DEFCLASS are 
     - to make it easier and more convenient for users to create
constructors
     - :CONSTRUCTOR is a convenient abbreviation for something you 
        could do yourself in a more long-winded way, just like :ACCESSOR

Isn't this another case of making something easier to type, and harder
to read?   We are talking about a few extra characters. Are the
following really MUCH more long-winded than the constructor option?

(defun make-foo (&rest initargs) (apply #' make-instance 'foo initargs))

(defun make-foo-2 (&key k1 k2) (make-instance 'foo :k1 k1 :k2 k2))

   [Another] reason to have a :CONSTRUCTOR option in
   DEFCLASS [is] 
     - to be culturally consistent with DEFSTRUCT

We certainly have ignored the notion of being "culturally consistent
with DEFSTRUCT" -- to quote Moon "that syntax was designed a long time
ago".


(2) Coordination with class redefinition

Moon argues that creating an option makes constructors lexically local.
But the validity of the constructor is dependent on information that is
inherited from many classes and methods.  Hence being included in the
class definition is not as useful as say the :initarg or :accessor
slot-options, which are adjacent to all the information used in their
construction.  And :initarg or :accessor slot-options don't effect
anything in subclasses (except for optimizations)

    Making this updating automatic is a convenience for
    programmers, so they don't have to remember to do it by hand.

I don't undertand which things can be done automagically.  If I change
the name of an initarg or method keyword argument, should the text in
which constructors used the old name be changed?  Clearly not.  What
other changes can be handled that are interesting?  What Moon is
suggesting is a general mechanism for notifying the user when the names
of keyword arguments change in a method, so calls can be changed.  

    (3) More efficient than MAKE-INSTANCE
  ...
    Gregor has argued that calls to MAKE-INSTANCE with a constant
    first argument can be equally optimized
  ...In either case, if we are going to have this type of
    mechanism, I would much rather make it explicitly visible as a
    :CONSTRUCTOR option than have it operating behind the scenes in
    some vaguely defined way.

But I thought the whole point of optimization mechanisms is that they
would operate behind the scenes.  I don't quite understand the phrase
  "the inherent complexity of making that mechanism generally available"
in this context.  I thought this was specific to make-instance, and that
the only other mechanism was a hidden mechanism for generating functions
from a particular type of call, rather than the optimization tricks.

My high order conclusion is that
 -  constructors are for writers of code, not readers, 
 -  optimizations should be for system implementers,
    not something that we force the casual user to be aware of
 -  programming environments should support finding callers of methods
whose arguments have changed.  We might ask what hooks CLOS should
provide for such an environmental feature.