'james

Solution #1 This is not meant to be flippant.
Just never write any code that instantiates the class.

Solution #2

(defmethod initialize-instance :before ((obj forbidden-abstract-class) &rest
initargs)
    (error "Cannot Instatiate Abstract Class"))

if you have this concern a lot, you can define a macro:

  (defmacro abstractify (classname)
   `(defmethod initialize-instance :before ((self ,classname) ..etc..

an approach from the other direction would be:

  (defclass rootmost ..whatever)

  (defmethod i-i :before ((self rootmost) &key instantiable
&allow-other-keys))
   (assert instantiable))

  (defclass instantiable ()
    ()
    (:default-initargs :instantiable t))

then inherit instantiable as needed. or flip the arrow with an ABSTRACT
mixin class.

if you want fully to recreate C++ under CL, maybe a metaclass would be
in order.

kenny
clinisys

You probably want to define an eql-method on make-instance instead:

(defmethod make-instance
    ((class (eql (find-class 'forbidden-abstract-class))) &rest initargs)
  (error "Cannot Instatiate Abstract Class"))

[ Sidenote: In CMU CL you need to use pcl::find-class here ]

Regs, Pierre.

Of course if I have to extend make-instance the question arises
whether this might be costly.  I expect to see lots of instantiation
with no regular pattern during use, so I suppose that I have to decide
which would cost more in the long term: writing explicit checks all
over where assumptions are being made, or slowing down the
make-instance generic with an extra eql method.

'james

(defclass abstract-class-mixin ()
  ())

(defmethod initialize-instance :before ((object
                                         abstract-class-mixin) &key)
  (when (member 'abstract-class-mixin
                (mop:class-direct-superclasses (class-of object))
                :key #'class-name
                :test #'eq)
    (error "Can not instantiate abstract-class")))

(defclass abstract-class-1 (abstract-class-mixin)
  ())

It is easy to use. Makes also easy to collect or browse all the
abstract classes

You could define a macro such as :
(def-abstract abstract-class-1 ()
  ())

This will allow to change easily the implementation if performance is
a problem.

It's at http://www.tfeb.org/lisp/hax.html#ABSTRACT-CLASSES (this URL
will likely change as I have a huge chunk of stuff I want to put up
there and reorganise it all, but probably there will be a forwarding
pointer at least, and anyway it will be about 10 years before I get
around to doing it...)

I'm with those that think disallowing instantiation might not be such a
great thing to try. Getting into the MOP is relying on a vendor-specific
standard, and thus has its own problems. The only other reliable way I
can think of is to list every function that might be used to create or
modify the instance, and stick an error message on to it.

[ The rest of this message is directed at James Crippen, the original
poster...]

And before doing so, I'd ask myself if it is worth the trouble... The
reason for the meta question is that it is highly improbable that lisp
programmers would try to instantiate the root class instance, if you
advise against it in your documentation. (What would they do with it
anyway?) What you might be looking for is the detection of accidents. I
don't think that should be your responsibility, at least while you are
dealing with decent lisp programmers. Now, if you are using this as a
pedagogical tool, or aiming it at other lisp newbies, it might be a
worthwhile goal. But that doesn't sound like what you are doing either.

Perhaps we ought to help with your intent rather than the question you ask?

Sunil

All in all I think MAKE-INSTANCE and CHANGE-CLASS are the right places
where to intervene, since the are not operating on an instance yet.

Of course it's two places to change....

Cheers

And the speed of cases where the eql method matches is not very
relevant, given that an error will be raised... ;)

Regs, Pierre.

If not then doing the make-instance hack, or something similar is
probably your best bet.

It usually pays to not worry about CLOS performance, except for the
very tightest inner loops.

Regs, Pierre.

I guess I should try it with CMUCL, and see what happens...

The situation is identical in CL.

[There are differences, in that the inlined code will also have to
check for changes in the class-hierarchy (including the effects of
class redefinition), which Dylan can sometimes avoid, given sealing
declarations for the relevant classes.  That shouldn't come into play
here at all]

Regs, Pierre.

It very common in high peformance Dylan code to see this idiom: (example
from
http://berlin.ccc.de/cgi-bin/cvsweb/gd/examples/ICFP2001/src/attribut...
ylan?rev=1.13):

define functional class <attribute> (<object>)
  slot value :: <integer> = 0,
    init-keyword: value:;
end class <attribute>;

define sealed domain make(singleton(<attribute>));
define sealed domain initialize(<attribute>);

With these declarations, "make" and "initialize" are inlined and don't
check anything, even though their GFs are open.  Anything in another
library or at runtime that would invalidate the assumptions made by this
optimization will throw an error, so safety is maintained.

"functional" is an extension to the DRM language spec.  It enables
objects of the class to be stored on the stack and passed by copying
rather than allocating them on the heap and passing them by reference.
e.g. it causes "eq" to be defined as the same as "equal".  Sometimes
this is a win, sometimes it isn't.  In this case it proves to be a big
big win.

Adding the "sealed" attribute to a slot applies "define sealed domain"
to its getter and setter GFs.  Adding the "sealed" attribute to a method
applies "define sealed domain" to that GF with those argument types.

I'm with those people who feel that mucking with the MOP is a bad idea
because of the inherent portability problems that can occur.  I'd
really rather not end up having to debug MOP problems that could have
been avoided otherwise.

'james

Even if you add a method to, say, make-instance, there is nothing to
stop a determined user from removing it again, or adding their own
method that just calls next-method in place of yours.

Stroustrup says that the protection mechanisms in C++ are to prevent
accident, not fraud.  I think that applies here too.  If it was
important I think I'd probably add a method to make-instance rather than
rely *only* on the documentation.  That's not totally foolproof as there
is always a bigger fool (cue: Erik), but it's probably enough.

An interface in Lisp is, roughly, a collection of generic functions.
Methods provide the implementation; you define methods that take arguments
of your classes and that's it. There is no commonality that needs to be
factored out into bases that everyone must declare in their supeclass
list.

Interface bases are simply an artifact of a static type system.  The whole
purpose of an abstract base class in C++ is to make its single dispatch
run fast; the program has something to aim a pointer at so it can get a
hold of a vtable, and indirectly call to the implementation of a virtual
function in some base somewhere. The type of the base class pointer,
along with other constraints in the language, provide static assurance
that the machine language translation can blindly index into the vtable
and perform an indirect call.

  The near hysterical need to protect programmers from doing stupid things
  has always mystified me.  E.g., if you need to control access to your
  class slots with public, protected, and private, this only means that you
  are telling too many people too much.  If you give people a source file
  that contains all the names of all the slots with a silly string to make
  access difficult, all that your protection scheme relies on is that your
  users are unable to edit that file, which is obviously nuts.  Instead of
  protecting yourself from problems, you force people who think you made a
  mistake to edit the file or make a copy, and then they get out of synch.
  Of course, people would go "oh, no, you should not do that" if you said
  you had done this, but that is the core of this social protection scheme
  -- it has _nothing_ to do with what is in those files.  Since programmers
  who want to add a method to a supposedly public class will have to engage
  in header file editing, already, the threshold to do this is much lower
  than one might think.  Of course, maintaining "bit-level compatibility"
  with other code compiled with the unedited header file is kind of hard,
  and may lead to all sorts of hard-to-detect problems, but trust me, this
  is done all the time, because the languages are so stupidly designed.

  Common Lisp tends to assume that programmers are not lunatics who need to
  be protected from themselves.  So instead of forcing people to read and
  then edit or copy "header files", they have the introspective abilities
  they need right there in the development system.  And Common Lisp folks
  go "oh, no, you should not do that" if you use slot-value to access a
  slot that has not be documented to be publicly accessible.

  Similarly, the "pure abstract class" is a compile-time issue in some
  "object-oriented" languages, but if you trust programmers not to do so
  many stupid things, the only protection you need is already there: There
  are presumably no generic functions that would dispatch on the class that
  should never be instantiated.  (This would apply to mixin-classes, for
  instance, which are only supplying some new slots and/or supply a method
  that is already known to exist in the classes they are mixed in with.)

  In other words, you should already have the necessary mechanism in your
  code if you simply omit methods that dispatch on the abstract class.
  Is this not sufficient?

  Are there really no psychiatrists near you who could help you get over
  your coping problems?  No friends or anybody else who cares about you who
  could tell you to get over your personal problems?  No girlfriend, not
  even a _pet_ who can tell you that you have lost your mental balance?

  You keep attacking me for no reason at all.  I find your behavior pattern
  evidence that you actually _are_ retarded, specifically: devoid of the
  prerequisite intelligence to understand what you are doing to yourself.
  Thus, you are not _able_ to control yourself, but will continue to make
  similar idiotic remarks in the future, in order to prove that you are an
  asshole on a mission.  Your next idiotic remark of the same kind will be
  the only proof we need of your mental state and that you should be put in
  global kill-files.