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: forthcoming object system


   From: julian.gosnell@nomura.co.uk
   Date: Fri, 18 Sep 98 11:05:07 +0100

   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.

Some random thoughts ...

Trying to be all things to all people is a losing propostion, IMHO.
I hope the guile architects won't try to do this.
I've never used CLOS and have only read AMOP, but it tries to strike
a balance between giving some flexibility without going overboard.

I have a moderate preference for what you call Single dispatch, though
I have a fuzzy notion that Multiple dispatch is more Schemey
(is this fuzzy notion wrong?)

As someone who is anxiously awaiting for GOOPS (as good a name as any other),
I hope we can make some serious progress on this, but until we have
a design, can't do much hacking ...

[btw, for guile, it's reasonable to tie the OOPS in the module system, right?]