Re: New g-wrap supported in guile-gtk--rotty-0.1!

[Andy Wingo]

A late reply, as I'm cleaning out the old inbox...

On Thu, 04 Dec 2003, Mikael Djurfeldt wrote:

> An improvement of method addition on the algorithm level that could
> help this particular case would be to allow for adding multiple
> methods at once.  Presently, every call to scm_add_method involves
> re-computing the methods list of the GF which means that adding N
> methods to a GF is O(N^2).

I wouldn't think this would be the major problem. Guile-gtk is peppered
with methods on objects of all names, and really it's just for
convenience that they are grouped into generic functions. They are not
generic functions in the semantic sense (i.e. a defined operation that
can be documented).

So what you end up with is GF's like `remove-tag', with only one method
(gtk-tree-buffer-remove-tag in this case), that just serve as
abbrevations for the underlying functions when you know what kind of
object you're dealing with. The optimization problem is different: We
want to make many generic functions with few methods, not the other way
around.

Perhaps making a specialized `add-method!' delay method addition to a
specialized `no-method' would be the best option in this case.

The only other two things done upon initialization are the creation of
GOOPS wrappers for all object types and the bindings of the subrs. The
subrs go quick, IIRC, it's now just a case of making the GOOPS objects
quickly. But that's another bridge to cross, eh...

regards,

wingo.

p.s. It could be that this whole generic-function business is a mess,
and should really be implemented as methods-on-objects (the underlying
model) rather than methods-of-generic-functions. I haven't made a strong
opinion on this yet, but I do know that it's damn convenient to say
(hide widget) rather than (gtk-widget-hide widget).