[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
I don't think the difference between;
(make-foo :name 'bar :number-of-widgits 50)
(make-instance 'foo :name 'bar :number-of-widgits 50)
is sufficiently large to constitute a useful addition in
The difference is the same as between
(send object :do-this ) and (do-this object).
Most programmers will want to name their constructors in a way which
is reflective of their function, to construct a particular class. Thus,
if they change the class name, it would make sense to change the
constructor name, so that the name continues to reflect the function.
Whether they change a constructor function name or a class name in
a MAKE-INSTANCE form makes little difference. Thus, for the price of
yet another DEFCLASS construct, you get very little in the way of
additional abstraction. And, as has been argued, programmers who
want to do this will do it anyway. Most programmers are going to
want to do things like:
(defun make-bar-foo (widgits)
(make-instance 'foo :name 'bar :number-of-widgits widgits))
You do that by adding the following option in the defclass:
(:CONSTRUCTOR make-bar-foo (number-of-widgits &aux (name 'bar)))
This option is textually close to the initargs declaration, which is
another advantage over a separate constructor function.
and constructors won't help there. Or, if they could, the addition to
the DEFCLASS syntax wouldn't be worth the savings in not having to define
the constructor seperately.
The only argument I find vaguely attractive is the optimization one,
though I suspect this is probably more of an issue on dedicated hardware
than on general purpose machines. However, since the general Common Lisp
method of specifying optimizations is using the DECLARE construct, I
think any attempt to optimize instance construction should go that route.
I don't think that the value of the constructor option as an aid to
optimization has anything to with the architecture of the machine. On
any architecture, if you implement MAKE-INSTANCE by interpreting the
various data structures (initargs list, default initargs), it is going
to be costly. You will need a mechanism to generate some specialized
code reflecting the interpretation for a particular class. If we don't
standardize the mechanism, every implementation will do it its own way,
including the programmer tinkering with metaclasses. I is better to
agree one a general mechanism. That's what the second part of Moon's
proposal is all about.
And I reiterate my "YES".