[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Problems with SETF and structures
>Using CLOS, there is a better solution to your problem. Using CLOS and
>taking advantage of one of the cleanup committee's proposals to cleanup
>setf there is an even better solution.
>Solution 1 - Using CLOS.
>(defsetf foo-a set-foo-a)
>(defsetf foo-b set-foo-b)
.
.
>(defun test ()
> (let (x)
> (add-named-class
> :name foo
> :superclasses ()
> :slot-specifications '((a :reader foo-a
> :writer set-foo-a)
> (b :reader foo-b
> :writer set-foo-b)
> .
> .))
> (setq x (make-instance 'foo))
> (setf (foo-a x) 1)))
I fail to see the advantage of defining structures on the fly if
you must define their accessors up front. How can the method above
handle the situation if, for example, the slotnames or object name are
unknown at compile time. E.g.:
(DEFUN Make-Thingy (name slots)
(ADD-NAMED-CLASS :name name :superclasses ()
:slot-specifications slots)
(LET ((x (MAKE-INSTANCE name)))
(SETF <name-slot-1 x> 1)
x))
where <name-slot-1> is some notation for the accessor to the first slot
of this new structure.
>Solution 2 - Using CLOS and cleanup up setf
>The basic difference is that you don't have to do the defsetfs. The
>reason is that setf is defined to expand into a well-know function when
^^^^^^^^^ ^^^^^^^^
>there hasn't been an explicit defsetf done.
>(defun test ()
> (let (x)
> (add-named-class
> :name foo
> :superclasses ()
> :slot-specifications '((a :accessor foo-a)
> (b :accessor foo-b)
> .
> .))
> (setq x (make-instance 'foo))
> (setf (foo-a x) 1)))
I thought the idea behind add-named-class is to allow the creation on the
fly of new structure classes. Since the structure is not created until run
time, how can the compiler know at compile time how to expand
(setf (foo-a x) 1)?
If the compiler simply expands out the add-named-class at compile time,
thereby defining foo-a and its setf form, how does this differ from
(defstruct foo a b ...)
(or its equivalent in Flavors or LOOPS)?
As a further question, what is supposed to happen if two different functions
each are capable of defining structure FOO, and a third function uses a FOO-A
accessor? Depending upon which of the other two functions is run first, FOO-A
could refer to either of two different slots in the actual FOO structure.
What is a compiler supposed to do with that? How is the compiler supposed to
distinguish FOO-A, a FOO accessor defined by both functions, from FOO-B, which
is only defined by one of the functions, from FOO-C, which is a typo and
should generate at least a warning?
David Loewenstern
AT&T Bell Labs -- Whippany, NJ
{backbone}!rutgers!moss!whuts!davel -- or -- loewenst@paul.rutgers.edu