Some questions about GOOPS and CLOS in general

[Jost Boekemeier <jostobfe@linux.zrz.TU-Berlin.DE>]

Hi,

last weekend I looked at the guile OO system "goops" which implements
the CLOS OO paradigm.  Maybe someone could answer me the following
(probably silly) questions:

* The class X inherits features from two unrelated classes piano and bike.
  (I don't have a better example at the moment :>)
  Both classes A and B export a feature with the name "pedal".
  How can X access the feature "pedal" inherited from piano *and*
  the feature "pedal" inherited from bike?
  In most other OO languages it is possible to rename a feature
  inherited from a super class.  Is this possible in GOOPS?

* The interface seems rather strange to me. For example
  GOOPS uses getter and setter functions to access slots.
  A more "natural" way would be:
  (<class> <constructor> args) -> <object>
  (<object> <feature>) -> get value ("getter")
  (<object> <feature> args) ->  set value ("setter")

* In CLOS classes don't own (polymorphic) methods.  Instead
  it is possible to associate a polymorphic method called "generic"
  to a class.  The problem is, that it is not possible to
  "ask" a class about the methods it supports.  For example
  if you want to write a class that stores itself onto 
  a persistent store, the class has now way to store the
  methods associated with it.

* The CALL_GF1 macros.  These macros look up variables on
  module level and then call methods stored in these variables.
  The environment cache update and unmemoization protocol will
  notify goops when their locations change (goops registers
  observer procedures with env-observe-weak() etc.).
  No problem so far.

  The problem I see is that goops doesn't specify in which module
  (in which environment) these variables should be looked up.
  The current module system uses a state variable which tracks
  the "current module".  The module_lookup_closure looks up
  symbols in the "current module".
  Unfortunately (or fortunately :>) the new module system 
  is state-less.  There is no such thing as "the current module".
  If you want to evaluate an expression or look up a variable you
  must specify in which environment you want to evaluate the 
  expression or look up the variable.

* I don't understand the structures at all!  Why do structures have
  the type cm_tc3_cons_gloc?  I do understand that the car of the
  structure specifies the layout of it's cdr.  And the cdr's layout
  is the template for a new struct (the sub-type) and copied to the car
  of the new struct.  Why so complicated?  

* The class' slots seems to be implemented as a list.  Isn't it possible to
  store them directly into the class?



Jost