Re: should GOOPS be built-in?

[Michael Vanier <mvanier at bbb dot caltech dot edu>]

> 
> Michael Vanier <mvanier@bbb.caltech.edu> writes:
> 
> > No offense meant, of course.
> 
> I think you raise questions which are valid in themselves.  It was
> wrong of me just to dismiss them the way I did.  It's just that I know
> that it is a good decision to incorporate GOOPS into the core, and I
> didn't have patience (or time!) to enter the debate which I expected
> to be ignited by your posting.
> 
> So, I'm clearly the one who should apologize.
>

No problem.  I know how you feel.

> > However, assuming GOOPS is built-in, how does this affect the
> > possibility of adding/using alternative object systems that provide
> > more information-hiding than GOOPS-type object systems do?  This
> > *will* be an issue where translators are concerned, and maybe even
> > independently of that.
> 
> As others have said already supporting GOOPS in the core will
> certainly not make it harder to add other object systems.  It's
> probably the other way around.  We'll still have the option of either
> adding/using an entirely different object system or emulating it in
> GOOPS.
> 
> I'll show you an example of how the MOP in GOOPS can be used to adapt
> it's behaviour.  (I discovered a few bugs while writing this example,
> so you'll have to use the very latest source from CVS for it to work.)
> 
> Imagine that we have a class library L exporting the class c:
> 
> (define-module (L)
>   :use-module (oop goops))
> 
> (export c b)
> 
> (define-class c ()
>   (a #:accessor a #:init-value 1)
>   (b #:accessor b #:init-value 2))
> 
> Note how we leave the task of information hiding to the module system:
> b is made public since it is exported, while a is private.  (Maybe we
> should add a keyword #:public-accessor which does the export
> automatically?)

That would be nice.

> 
> Now, imagine that we use L this way:
> 
> (use-modules (oop goops) (L))
> 
> (define-class d (c)
>   (a #:accessor a #:init-value 3))
> 
> In GOOPS, you are supposed to know which slots the class c has, so the
> slot a in d should not be interpreted as a new slot but rather as a
> redefinition of the slot a in c.  This is probably the problem of
> information hiding which you are referring to.  Am I right?

[Interesting example of using the MOP to get around this problem omitted.]

Actually, I was thinking on a much more primitive level.  The first example
you show addresses the problem I was thinking of, which is how to have
private (or, for that matter, protected) instance variables.  Essentially
I'm wondering how one would use GOOPS to emulate C++-style object systems
(or, for that matter, the object systems of Eiffel or python) which provide
information-hiding on a class-by-class basis.  You can do that with GOOPs
by making each class into a separate module.  BTW this is effectively what
Eiffel does, although the emphasis is different: in Eiffel, each class IS a
module and there is no notion of module separate from the notion of class.

One advantage of the GOOPS system is that several related classes can be in
the same module and can have access to all of each other's slots.  These
are analogous to "friend classes" in C++.  However, if you wanted to define
several unrelated classes in one file (I'm not saying this is a good idea,
but people do it all the time in other languages), you'd have to define
several modules in one file.  Is this possible?

Also, is there any way to implement a "protected" slot in GOOPS i.e. a slot
which can only be accessed by an instance of a subclass?  For what it's
worth, I don't know of any scripting language that can do that.  You could
always have a convention for accessors e.g. accessors starting with _
should be considered protected and should only be used by subclasses.
Still, this falls short of real information-hiding as I understand it.
Eiffel has an even more sophisticated export control system whereby a given
member can be exported to only certain particular classes and their
subclasses.  If one wanted to implement things like that in guile, it's not
clear to me whether it would be best to build it on top of GOOPS or to
build a completely new object system instead.  However, I agree that GOOPS
will probably be more than sufficient for 99% of cases.  But since we want
guile to be the scripting-language-to-end-all-scripting-languages (or at
least I do :-), I do like to think about the other 1% of cases.

Mike