This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re[2]: forthcoming object system


> > I've seen a skeleton of the forthcoming guile object system in the new 
> > snapshots, probably an undocumented feature whose usage is yet strictly
> > discouraged.
> 
> Do you mean objects.[ch]? I think Mikael startet working on a object system
> called "goops":
> 
> (define cl (make-class-object <operator-metaclass> "pwpwpw"))
> (set-object-procedure! cl (lambda (a . x) (display x)))
> (define ob (make-struct cl 0 (make-struct-layout 'pwpwpw)))
> (ob 1) -> (1)
> 
> The problem with the current implementation is that it is based on
> structs, which  aren't very well designed (IMHO). In a dynamic typed
> language like guile a class should be an object and vice versa.
> 
> 
> > Will it be possible to access modules defined in scheme in the new built-in 
> 
> Are you talking about Objects or Modules? 
> 
> 
> Jost

I haven't been paying much attention to any discussion about a Guile object
 system which might have taken place - so please forgive me if I go over
 well-trodden ground.

I am aware of two major Object System paradigms.

Multiple dispatch - behaviour is not encapsulated by classes, but rather
 supplied by generic functions. Alternative boundaries (e.g. modules) may be
 used to enforce public/private distinctions. e.g. CLOS, Dylan

Single dispatch - behaviour is encapsulated by class boundaries and
 public/private distinctions tend to be enforced on the same boundary. e.g.
 Smalltalk, [Objective-]C[++], Java.

There is no point in getting into a religious war about the comparative features
 of each one. All I ask is that whoever writes THE guile Object System takes
 into account that whichever he chooses he will come across people who want the
 other (or maybe even prototyping like Self). With this in mind we should be
 considering what all these paradigms have in common and building a layered
 framework which might support, at different levels, any conceivable variant.

I am currently using tiny-clos and would be interested in any underlying
 framework onto which I could move the implementation to give me speed gains.

The above example does not really contain enough information for me to fathom
 which way GOOPS is going - is there some other discussion group. I'm sure I
 haven't seen much posted here. Can anyone tell me more ? Have I missed
 something ?



Jules