On Tue, Dec 23, 2003 at 02:08:16AM -0900, James A. Crippen wrote:
> Christophe Rhodes <csr21@...> writes:
> > I'm no MOP expert, but I think ENSURE-CLASS and ENSURE-CLASS-USING-CLASS
> > are the functional interface to class creation. Something like:
> > [untested]
> > (sb-mop:ensure-class 'bar
> > :metaclass (find-class 'standard-class)
> > :direct-superclasses (sb-mop:class-direct-subclasses (find-class 'foo))
> > :direct-slots nil)
> I found out about ENSURE-CLASS after some quality time with the AMOP,
> and it looks like what I'm looking for. Thanks for the example.
> > I don't think so; (documentation (find-package "SB-PCL") t) indicates that
> > the SB-PCL package is only semi-public, and could change at any time. It
> > would be irresponsible to document it...
> Okay, perhaps you're right. But there's nothing wrong with admitting
> that PCL is in use. It's nothing to be ashamed of... :-)
Yes, but we tend to be finicky about what we commit to as interface.
We can be unashamed of using (now somewhat munged) PCL without being
comfortable promising that the internal implementation details of PCL
will be available in future releases.
Imagine "you don't need to be ashamed of using low-level pointer
hackery to implement your hash tables." Right; but it doesn't follow
that the low-level hackery used in the implementation of hash tables
should be exposed and documented, instead of treating it as an
internal implementation detail. Similarly, I consider the PCLness of
our CLOS to be basically an implementation detail.
Note that this fussiness about interface vs. implementation may in
this case not be just rote repetition of an abstract software
engineering design principle where we don't understand the practical
tradeoffs involved. We've already hacked on the PCL code quite a lot,
and we could easily be on track to hack on it quite a lot more. (I
think, and at last report Christophe thought too, that it could be
rather nice to get rid of the pre-CLOS constraint on the compiler's
implementation. To do this, we'd probably need to get rid of the "warm
init" phase of SBCL's build process, which in turn would probably
require bootstrapping CLOS at GENESIS time, which might well require
deep changes of some sort.)
> > ... particularly when (documentation (find-package "SB-MOP") t) both
> > indicates its presence as a public extension, and points to reference
> > material about its interface.
> But it's not documented in the User Manual as far as I can see. Which
> was my real complaint. I couldn't find anything about "MOP" or "CLOS"
> while looking through the manual at http://sbcl.sourceforge.net/manual.
I think everyone would agree that the user manual is less than ideal,
and its current state doesn't reflect a belief that it's the best of
all possible user manuals, but is a compromise given that we have a
limited supply of the combination of motivation and knack that would
William Harold Newman <william.newman@...>
In examining the tasks of software development versus software maintenance,
most of the tasks are the same -- except for the additional maintenance
task of "understanding the existing product". -- Robert L. Glass, _Facts
and Fallacies of Software Engineering_
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C