Subject: Re: Preventing a class from being instantiated
From: Erik Naggum <>
Date: Fri, 30 Nov 2001 05:55:15 GMT
Newsgroups: comp.lang.lisp
Message-ID: <>

* James A. Crippen
| From what everyone on this thread has said, I've come to the conclusion
| that the best thing I can do is make it very clear to the users that
| instantiation of the abstract classes is a bad thing, noting it in
| documentation and source code.  Also, adding some checks for assumptions
| about the abstractness of classes in the places where it will do the most
| good for preventing mistakes.  Being Lisp I'm not going to write
| *everything* in the style of an overdefensive C programmer, but I won't
| gratuitously assume that everything in the system is in perfect working
| order.

  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?

  The past is not more important than the future, despite what your culture
  has taught you.  Your future observations, conclusions, and beliefs are
  more important to you than those in your past ever will be.  The world is
  changing so fast the balance between the past and the future has shifted.