This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: Some questions about GOOPS and CLOS in general
> Care to mention any working module system whose imports are all
> implicit?
Eiffel for example.
However, what I don't understand:
1. You say that modules and a type system are two orthogonal concepts.
2. You say that the module handles encapsulation on behalf of the class' objects.
3. You say that a module can contain more than one class.
Sorry, but these statements can't go together.
> he whole point is that with class = module, you
> can prevent yourself from introducing unwanted side effect
Yes.
> ut you can not allow yourself to introduce wanted side effects.
Could you please explain that? Please note that a module is not a package
and that modules from the same package can access protected entities.
I really think you confuse modules with the package concept.
For example
(module (ice-9 test1) (module (ice-9 test2)
(open (ice-9 debug)) (open (ice-9 debug))
(export a b c) (export a b c))
(protect internal))
(define internal 12) internal -> 12
(module (snow-white test3) ;; note: a differend package!
(open (ice-9 debug) (ice-9 test1))
internal -> error undefined
> > I think when you say "module" you really mean the package concept.
> > If I understood Mikael correctly there is exactly one class per module.
> Either you misunderstand Mikael or this should be corrected.
> Modules are unrelated to classes.
> Except in bondage & discipline OO languages.
Okay then. Consider a person who wants to write a package and
writes classes A and B which both have the feature (translation: the "slot")
"pedal" and the person wants to publish their interface. Do you want to force
the person to use two differend modules just because you use the strange
concept that a module handles encasulation on behalf of classes?
> Encapsulation and OO are separate issues.
No. But modules and classes are two orthogonal concepts.
As I said, the module handles the physical and the class the
logical structure. But they *both* handle encapsulation.
>> class piano has slot pedal
>> class bike has slot pedal
>>
>> class s inherits from piano and bike.
>> You must not merge these two slots.
> Well, how would you do it in Java?
This is not possible. That's because Java doesn't support multiple
inheritance. You must write and use an interface instead.
But this is of course possible in eiffel and other oo languages.
> Unless, of course, you use the module system to rename one of the
Again, Java and Eiffel don't have a module system. In Java
and Eiffel the module is a class and a collection of classes
is called a "package" (see package example above).
> Let's see. Class (by definition) is set of values. Type (by
> definition) is set of values
Ups! A type is a set of values?
>> I don't understand. Depending on the type of m1 format is either
>> binary-formatter or text-formatter.
> Nope.
>(define m1 17)
>(format m1 formatter)
It is:
(m1 format) -> 17
(m2 format) -> "17"
(m3 format) -> 17.0
etc...
>> > (generic-set! (get-nth list 5) 15)
>>
>> What does that do? As I understand scheme you cannot set! a list
>> to something.
>Check setf in Common LISP and reread discussion on generic set on this
>list.
So what exactly are you talking about? About common lisp or the
syntax for an OO system for scheme?
The above syntax is at least as strange as the lambda with more
than one entry.
Jost