Subject: Re: All instances From: Erik Naggum <erik@naggum.net> Date: Sun, 17 Jun 2001 23:33:34 GMT Newsgroups: comp.lang.lisp Message-ID: <3201809612265140@naggum.net> * David Bakhash > If what you want is to keep track of all instances of arbitrary > classes, then you may consider defining a new metaclass for this. * Christopher Stacy > That is not available in ANSI Common Lisp (the MOP is not part of that > language), although some vendors support this. Vote with your feet when it comes to supporting the MOP. If the vendor does not support it, just walk away. If people are told not to expect the most basic features above and beyond Common Lisp because it is not in the standard, the language will die. In fact, I consider the fact that people are willing to whine about feature X not being in the standard as the reason that Common Lisp has seen little development. The point with a standard is not to ask what is in it, it is to ask whether that which is in it is implemented, and whether that implementation is according to that standard. If it is not specified in one standard, it may be specified in another standard. MOP is a community standard that merits about the same level of authority within the community as ANSI does for the greater community. Similar efforts have been attempted with other features that people need, too, but instead of writing standards-quality stuff to support an implementation, some people prefer to post only the implementation, which is completely useless to people who are used to having a really good standard to refer to when they need to understand what to _expect_ from an implementation. (Many other languages are the other way around: That the implementation _is_ the specification.) MOP _is_ part of the Common Lisp toolchest and the common environment that surrounds the language proper. This is one of the reasons it is not a lot of work to build a Common Lisp interpreter or compiler (as is often done with Scheme), but a lot of work to build a Common Lisp _system_ (as is ofte not done with Scheme). If we do not appreciate the systems, but only the language, we have no chance at all against languages that have successfull merged to two concepts, such as Perl and Java. The only way to _make_ vendors support stuff people need is to make sure they are chosen if and only if they do. In the case of the "Open Sores" community, their biggest problem is that they do not want what they have not got, in particular, the lack of willingness to implement what is in the commercial offerings, coupled with a lack of willingness to use what is only in the commercial offerings, making sure that the willingness to implement it is never going to materialize, either. #:Erik -- Travel is a meat thing.