This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: Goops and the module system
- To: Craig Brozefsky <craig at red-bean dot com>
- Subject: Re: Goops and the module system
- From: Jost Boekemeier <jostobfe at linux dot zrz dot TU-Berlin dot DE>
- Date: 03 Mar 2000 15:56:14 +0100
- Cc: guile at sourceware dot cygnus dot com
- References: <20000127120716.29627.qmail@web1805.mail.yahoo.com> <200001280904.JAA00754@ossau> <38918B07.F7DDA4A7@enteract.com> <m3vh3at4d9.fsf@savonarola.red-bean.com> <p2tem9vrjku.fsf_-_@kirsche.zrz.tu-berlin.de> <7ebt4zubuv.fsf@zesoi.fer.hr> <s3ln43c1kn.fsf@verisity.com> <p2tg0u95i6b.fsf@apple.zrz.tu-berlin.de> <87k8jldr3c.fsf@piracy.red-bean.com>
Craig Brozefsky <craig@red-bean.com> writes:
> present CLOS application I am working on several supporting libaries
> as well as the framework that uses them.
Is it possible for you to grep all places in which the framework
*destructively* overrides a method solely specialized library classes?
> Sometimes I like to override definitions, adding some format calls,
> or maybe recompile the function with some breakpoints installed, or
> simply find a mistake or a better way to do it. Often these changes
> never make it to the source file, only appearing in my buffer and in
> the running image
Okay, but why is it necessary to change the class definition "in place"?
Can't you just make a virtual copy (inherit from the system class)
and change your copy?
[modifying modules]
> Redefining at runtime is critical IMO to the lisp (scheme included)
> development process.
External overrides have nothing to do with the module issue.
If you allow users to change classes (instead of adjusting the
inherited classes), you'll end up with a system like WinNT: Whenever I
install a certain telecom application, I screw up Winword because it
replaces functions and global variables in a library which Winword
needs.
Jost