From xemacs-m  Wed Apr 16 00:23:14 1997
Received: from martigny.ai.mit.edu (martigny.ai.mit.edu [18.43.0.152])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id AAA06796
	for <xemacs-beta@xemacs.org>; Wed, 16 Apr 1997 00:23:12 -0500 (CDT)
Received: by martigny.ai.mit.edu
	(1.40.112.8/16.2) id AA108198187; Wed, 16 Apr 1997 01:23:07 -0400
Date: Wed, 16 Apr 1997 01:23:07 -0400
Message-Id: <199704160523.AA108198187@martigny.ai.mit.edu>
From: Bill Dubuque <wgd@martigny.ai.mit.edu>
To: hniksic@srce.hr
Cc: xemacs-beta@xemacs.org, xemacs-beta@xemacs.org,
        emacs-custom@sunsite.auc.dk
In-Reply-To: <kigd8rw9lbf.fsf@jagor.srce.hr> (message from Hrvoje Niksic on 15
	Apr 1997 20:45:40 +0200)
Subject: Re: Specifiers in custom

I think all the various proposals about 'defcustom' options make
much more sense if you consider an object-oriented approach to
the 'symbols' defined by defcustom (i.e. the interface to these
objects should implement them just like symbols (or instance
variables) even if the values they reference aren't actually 
stored in a symbol-value slot).

First, the :get and :set methods could be unified if one has a 
true CL style SETF function. One should also be able to ADVISE 
these methods so to get :BEFORE and :AFTER daemons.

Other properties like :type and :group should just be general
properties on the 'symbol-plist', and the methods for looking
up such properties should also be advisable. (:type could also
be implemented via a general declare/proclaim mechanism for
any 'place' referenceable via setf).

At least one should keep in mind the object-oriented viewpoint
so that if/when we have better OO support we can easily convert
defcustom to use such.

Anyone who is designing such aspects of the language should at
least be intimately familiar with CL, where many analogous issues
have been hashed out at length by experts, e.g. see the online
version of CLtL2 and the ANSI CL spec.

-Bill Dubuque

