[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Constructors



    Date: Fri, 02 Oct 87 10:41:20 MDT
    From: kempf%hplabsz@hplabs.HP.COM

    ....In the case of a class option, the association between a
    constructor name and a class name is made in the DEFCLASS form, but
    the constructor must actually be defined in a seperate form, as a
    method or function.  From the point of view of someone reading the
    code (barring comments, of course) the fact that a particular method
    is a constructor is only apparent if they look back at the DEFCLASS
    form.

Jim, I'm afraid you misunderstood what I was proposing, in an important
way.  The :constructor option to defclass completely takes care of
defining the constructor; there is no separate form that "actually
defines" it.  Also, constructors are not methods.

Thus in your example

            (defclass udc () (a b c) (:constructor udc-cons))

            (defun udc-cons (a b c)
              (list a b c))

you are defining the function udc-cons twice.  First you define it
as a constructor, then you clobber that definition.
Your example is semantically the same as

            (defclass udc () (a b c))

            (defun udc-cons (&key) 
              (make-instance 'udc))

            (defun udc-cons (a b c)
              (list a b c))

As best I can tell, the rest of your comments aren't really applicable,
once this misperception is realized.  If after reading this you still
think there are problems with constructors, could you send another
message?  I certainly want to be aware of any real semantic problems.

At least one thing is clear from this, which is that if we put in
constructors the explanation in the spec will have to be written more
clearly than the explanation in the draft proposal I mailed out, so
readers cannot misunderstand it in this way.  I am not surprised by
this.