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: Generic functions


mike@olan.com (Michael N. Livshin) writes:

> 1.
> I took a look at the Guile sources and found that Mikael
> started implementing some sort of metaclass-based OO system,
> and that he defined an "operator metaclass".

Yes, GOOPS will be similar to tiny-clos and STKlos.

> 2.
> It appears to me that the evaluator is not yet aware of
> the fact that something other than closure can be apply'd.
> Is it true or had I overlooked something?

Other things than closures can be applied, however the user-level
interface to these evaluator facilities is not finished.  The reason
why I put it in there now is that I'm using it in the STk interface
port.

> 3.
> I was going to see how to add simple single-dispatch generics
> to Guile.
> <rant>
> Records and single-dispatch generics are all the OO support
> any reasonable design should ever need.  None of that hyped-up
> inheritance stuff.
> </rant>

I think inheritance is a powerful tool, useful for structuring
programs and for re-use of existing code.

> Ahem, anyway, after looking at Mikael's OO stuff, I thought that
> perhaps the right way to implement generics would be to define
> a class of the "operator metaclass".

It is probably not, depending on how you want to implement them.  A
class with an operator metaclass has the dispatcher stored in the
class object.  A generic function is more efficient if the dispatcher
is stored in the generic function object itself, i. e., in the
instance.  (This is because it already knows what function has been
requested, so it only needs to bother about the arguments.)  So, a
generic function should probably be a subclass of the entity class
which is an instance of the standard metaclass.

[...]

> Should I just shut up and wait till GOOPS surfs up?

I'm sorry, but in this case I think this is a good idea.  The reason
is that since GOOPS will provide generic functions, it doesn't seem
useful to implement a separate generic function facility.

The basics of GOOPS may surf up during the Christmas holiday.  :)

But perhaps I can contact you again if/when I discover that we can
work on this together?

Best regards,
/mdj