This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: Goops and the module system
Craig Brozefsky <craig@red-bean.com> writes:
> 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?
How can we? Generic functions do not respect module boundaries. And
I think the module system can't find the methods which are solely
specialized to system classes (== classes which do not belong to your
project). That's why I asked if it is possible for you to find the
methods which break the module boundary.
From Kiczales paper: "[...] we must prevent the user from redefining
specified classes, generic functions or methods[...] "
"FOOTNOTE: In general, CLOS allows classes, generic functions and
methods to be redefined. This is designed to support program
development and is not intended as a mechanism for the user to alter
the program someone else wrote".
[...]
"That is, the user cannot change the behavior of the draw method
specialized to the class text-button".
> > > 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.
You have a couple of system classes written by someone else. Now
imagine you draw a border around them. Let's call this border the
"system module border".
You are now designing several supporting libraries. Since they can be
used independently and you expect that people will use different
versions of these libraries, you have to put them into separate
modules also (-> "library module border").
After that you hack your framework. The problem is: Can you find
the methods that have no other specializers than system and/or library
classes? If you can't, how should the module system find them and
how should the module system check for name clashes?
Instead of breaking the module boarder, isn't it better to either
a) step into the module itself and change it or
b) tell the module system to which module the new method you're creating
belongs?
We can have both, but the module system needs a hint; a "module back
pointer", either implicit [see solution a] or explicit [solution b].
> 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?
No. I distinguish between methods that specialize _only_ on types
from other modules and methods that have at least one specializer from
the current module (of course, this specializer can also be the module
itself -- which is the solution that java uses.
> 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?
That's the same problem. You can do whatever you want with your own
classes (== the classes which reside in the current module) but the
module system must be able to restrict access to classes which other
people contribute. This simply means: No external overrides.
> The notion of external itself is a fiction supported by the module
> system.
Yes.
> If we have modules with an inside and an outside, where is the REPL?
Specified (and exported) by the module itself.
> If the REPL can move between modules
Umm, no, it can't. But that's a diffetent thing. There's exactly
one REPL per module. A TCL module may have a different REPL
than a normal scheme module.
> 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.
Where is "versioning" different than inheritance? It doesn't matter
if you make a virtual copy or a real copy (and give the new copy
a different name). It is important that you do make a copy and
do not change (or replace) the original library/class/module.
Jost