Re: Goops and the module system

[Craig Brozefsky <craig at red-bean dot com>]

Jost Boekemeier <jostobfe@calvados.zrz.TU-Berlin.DE> writes:

> 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?

I'm not sure I understand your question.  Assuming I'm using ILISP, I
can M-. and then M-, thru all of the method definitions for a given
generic function, assuming I have the source available (which is a
safe assumption IMO, because this is Free Software).  Doing this I
could find any redefinition of a method, wether it specializes solely
on library classes or not.  

Do you intend to distinguish between methods that specialize on types
from more than one module from those that specialize on types that are
all in the same module?  That seems like a confusion of what generic
functions are about.

In situations where I don't have source code, or I don't want to have
an override, but would prefer to wrap something around the existing
method, I use the :around method combination.  Again, these :around
methods would show up in ILISP using M-./M-,.

The comprehensions problem I'm having is what do you mean by the
"framework *destrutively overrides"?  The framework isn't the
programmer, I'm the programmer, remember Jost?  What is the difference
between destructively overriding a method and redefining it?  Nothing.
If I can't redefine things at runtime, wether they are in one of your
so called libraries or not, then the whole point of having an
interactive development environment with a persistent runtime as well
as iterative compilation and evaluation is lost!

Without this, how am I supposed to patch a running system without
shutting it down and reloading the so called "library" and then trying
to put it back online?  I suppose guile can jettison all of this in an
attempt to make it safe for lusers, but then you can kiss goodbye
guile in emacs, because you're gonna loose all the wonderful things
that even that crusty old lisp dialect elisp has.

> > 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?  

Because a dozen other objects in the application presently have a
reference to the object.  But changing the class definition only
changes the allocation of slots.  I'm talking about redefining generic
functions, and what does that have to do with class redefinition?

> [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.

The notion of external itself is a fiction supported by the module
system.

If we have modules with an inside and an outside, where is the REPL?
If the REPL can move between modules, then what is the difference
between redefinition at runtime and external override?  If the REPL
cannot move between modules, then how do I develop with it?

> 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.

Your example is fucked because the telecom app is most likely
replacing the entire library with a new version, not redefining shit.
Often winapps do this not because they want to add a new feature to a
base library, but because they ship with the needed system dlls and
god be damned if another app needs a different version, since dlls do
not support real versioning.  It has nothing to do with
redefining/overriding.  So it really has nobearing on the issue at
hand.

Can't we just leave modules, or whatever guile is goin to call them to
their job of managing namespace and keep them out of the misguided
code police racket?


-- 
Craig Brozefsky                      <craig@red-bean.com>
Free Scheme/Lisp Software  http://www.red-bean.com/~craig
"Hiding like thieves in the night from life, illusions of 
oasis making you look twice.   -- Mos Def and Talib Kweli