In my chapter on user-defined classes I use the term "user-defined"
classes to mean classes that are defined with DEFCLASS and are
instances of STANDARD-CLASS. In a footnote I explain that this isn't
exactly the right term because a) Users can also use DEFSTRUCT to
define new classses that aren't instances of STANDARD-CLASS and b)
classes provided by the implementation (i.e. not user-defined) can be
instances of STANDARD-CLASS.
But I couldn't think of any other term that was more accurate and
about the same length. As I explain in my footnote I don't want to
call them "standard" classes since that makes all the built-in classes
into what, "non-standard" classes?
I'm revising that chapter now so if someone can come up with a better
term in the next few hours I still have a chance to change it. Any
ideas?
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
In article <··············@javamonkey.com>,
Peter Seibel <·····@javamonkey.com> wrote:
> In my chapter on user-defined classes I use the term "user-defined"
> classes to mean classes that are defined with DEFCLASS and are
> instances of STANDARD-CLASS. In a footnote I explain that this isn't
> exactly the right term because a) Users can also use DEFSTRUCT to
> define new classses that aren't instances of STANDARD-CLASS and b)
> classes provided by the implementation (i.e. not user-defined) can be
> instances of STANDARD-CLASS.
>
> But I couldn't think of any other term that was more accurate and
> about the same length. As I explain in my footnote I don't want to
> call them "standard" classes since that makes all the built-in classes
> into what, "non-standard" classes?
How about introducing an acronym? UDSCs: User Defined Standard Classes.
rg
Peter Seibel wrote:
> In my chapter on user-defined classes I use the term "user-defined"
> classes to mean classes that are defined with DEFCLASS and are
> instances of STANDARD-CLASS. In a footnote I explain that this isn't
> exactly the right term because a) Users can also use DEFSTRUCT to
> define new classses that aren't instances of STANDARD-CLASS and b)
> classes provided by the implementation (i.e. not user-defined) can be
> instances of STANDARD-CLASS.
>
object-system-defined classes
object-system classes
clos-defined classes
or just
clos classes
Wade
Peter Seibel <·····@javamonkey.com> writes:
> In my chapter on user-defined classes I use the term "user-defined"
> classes to mean classes that are defined with DEFCLASS and are
> instances of STANDARD-CLASS. In a footnote I explain that this isn't
> exactly the right term because a) Users can also use DEFSTRUCT to
> define new classses that aren't instances of STANDARD-CLASS and b)
> classes provided by the implementation (i.e. not user-defined) can be
> instances of STANDARD-CLASS.
That footnote is a bit ambiguous (er, well, maybe inconsistent):
do you in fact want a term that means
1 "subclass of STANDARD-CLASS", or
2 "thing defined using DEFCLASS"?
(There might not be an answer to this question...)
If #2, then (b) isn't a reason why "user-defined" is the
wrong term.
"User-defined class" is a pretty good name, especially
if you intend meaning #2.
If you mean #1, then you could consider "standard-class"
(complete with hyphen, to alert the reader that something
a bit weird is going on). Or something like "ordinary
class" or "normal class", but that has some of the same
value-judgement problems that "standard class" does.
But "user-defined class" isn't so bad, especially as
you warn readers that there *may* be non-user-defined
"user-defined classes".
If you mean #2, then you could consider "DEFCLASS class"
or "DEFCLASS-defined class", but I really don't think
there's anything wrong with "user-defined class" that
isn't adequately fixed by a brief warning to the effect
that strictly speaking DEFSTRUCT defines classes too
but you aren't including those. And you've got such a
warning, so that's OK.
--
Gareth McCaughan
.sig under construc
Peter Seibel wrote:
> In my chapter on user-defined classes I use the term "user-defined"
> classes to mean classes that are defined with DEFCLASS and are
> instances of STANDARD-CLASS. In a footnote I explain that this isn't
> exactly the right term because a) Users can also use DEFSTRUCT to
> define new classses that aren't instances of STANDARD-CLASS and b)
> classes provided by the implementation (i.e. not user-defined) can be
> instances of STANDARD-CLASS.
Hmm, interesting. Not that I'm a Lisp wizard (as you all know), but as
this is being used as an introduction, how would you compare the Lisp
DEFCLASS type to a DEFSTRUCT? Someone reading this coming from C++ (and
let's not kid ourselves, this will be a lot of readers) are coming from
a language where there is no difference between class and struct (save
default accessibility: public for struct and private for class).
I can use generic functions and DEFMETHOD with structures, so obviously
that really isn't a difference. The only real difference appears to be
the fact that DEFCLASS allows you to inherit from other classes. An
interesting question that comes to mind is, why can't a DEFCLASS
inherit from a DEFSTRUCT?
Sorry, Peter, for bringing up more questions and not really answering
your question. However, I think answering these (and maybe one or two
more) questions, may answer your overall question.
Last, a quick 2-3 word "term" may not be what you need. You may want to
just take a paragraph or two and really "lay down the law" on the
differences between classes and structures in Lisp. In fact, C++
tutorials should do the same. It is quite amazing how many C++
programmers think there are huge differences between classes and
structs....
Jeff M.
--
http://www.retrobyte.org
··············@gmail.com
On Sat, 29 Jan 2005 19:33:48 GMT, Peter Seibel <·····@javamonkey.com>
wrote:
> In my chapter on user-defined classes I use the term "user-defined"
> classes to mean classes that are defined with DEFCLASS and are
> instances of STANDARD-CLASS. In a footnote I explain that this isn't
> exactly the right term because a) Users can also use DEFSTRUCT to
> define new classses that aren't instances of STANDARD-CLASS and b)
> classes provided by the implementation (i.e. not user-defined) can be
> instances of STANDARD-CLASS.
>
> But I couldn't think of any other term that was more accurate and
> about the same length. As I explain in my footnote I don't want to
> call them "standard" classes since that makes all the built-in classes
> into what, "non-standard" classes?
>
> I'm revising that chapter now so if someone can come up with a better
> term in the next few hours I still have a chance to change it. Any
> ideas?
>
> -Peter
>
Call me a bit thick but I can't really see that there is a problem.
You tip toe around the problem by never introducing defstruct.
As it is always possible, and even preferable, to do this it is not a
problem.
Hence it is assumed that standard-class means something derived from
defclass.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
John Thingstad wrote:
> Hence it is assumed that standard-class means something derived from
> defclass.
This itself is a fiction, because defclass is defined to be a macro, and
that macro must expand visibly into the functions that define a class.
Assuming the implementation provides the MOP, that function is some
version of ensure-class or ensure-class-using-class.
Peter -- You should perhaps look at the other places where the ANS makes
a distinction between things done by the implementation and things done
by the "conforming program," or restrictions placed on each. The term
"user" is indeed ambiguious with regard to a typical application, where
there may be a "user" application programmer and also a human "user" of
the application which might be, for example, sitting in Bangalore at a
telephone and computer terminal taking telephone orders for Practical
Common Lisp. These two users have are of course not the same.
For example, if you examing ANS 11.1.2.1 which documents treatment of
the COMMON-LISP package, the separate restrictions are placed on the
"Conforming Implementation" and the "Conforming Program." Perhaps these
terms could be useful.