[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
:accessor slot option
Date: Mon, 2 Nov 87 13:30 PST
From: Gregor.pa@Xerox.COM
I have become uncomfortable with the :reader and :accessor slot options.
Right now, at the very least, I would like to add a :writer option, I
may also want to remove or rename the :accessor option. The :writer
option would work in the obvious way:
(defclass foo ()
((a :reader foo-a
:writer (setf foo-a))))
This would allow someone who wanted to define a writer but no reader to
do it, it also makes the mapping onto the new setf proposal more
explicit.
I agree that adding a :writer slot-option is a good idea. This would
make some of my users happier. This makes the CLOS specification slightly
larger, but it's probably worth it. It certainly doesn't make CLOS more
-conceptually- complex.
I agree that in cases where you want both a reader and a writer its
probably too verbose, so we probably need to keep the :accessor option,
but what if we renamed it, maybe to :reader-writer or perhaps
:accessors.
The name :accessors is definitely out; mixed singular and plural option
names always lead to trouble. I don't think :accessor is too bad a name
to imply a function that works for both reading and writing. If I was
teaching CLOS to someone, I think I would teach them :accessor first,
as the one that you usually use, and then later say "actually :accessor
can be broken down into its two component parts, :reader and :writer,
in case you have your special reasons to want to get at them separately."
What about the plural option name :default-initargs? I think this is
the only plural option we have, except for :qualifiers and :specializers
arguments when making a method, and those are legitimately plural to
show that their values are lists.
The name :default-initargs can be justified on the basis that it can
default more than one "initarg", but it might be worth rethinking this
name to avoid plurality and to avoid the jargon word "initarg," which
has been demoted to a less prominent place in the CLOS specification
than it had originally. :default-initialization was the best name I
could come up with, maybe someone else can do better.