Subject: Re: Preventing a class from being instantiated From: Erik Naggum <erik@naggum.net> Date: Fri, 30 Nov 2001 05:55:15 GMT Newsgroups: comp.lang.lisp Message-ID: <3216088512589746@naggum.net> * 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.