guile-gtk-general
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Andreas Rottmann
Subject: Re: New g-wrap supported in guile-gtk--rotty-0.1!
Date: Thu, 22 Jan 2004 20:55:49 +0100
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)

Andy Wingo <address@hidden> writes:

> On Thu, 2003-12-04 at 02:25, Kevin Ryde wrote:
>> I wonder if some lazy initializing would be possible, like catch a
>> failed method dispatch and add only at that time.  (But my ignorance
>> of goops is pretty profound, so maybe it's not feasible.)
>
> This is really a direct response to Andreas' question a couple days ago,
> which I have read but don't have on my laptop...
>
> I think I said something like make `add-method' cache methods, only
> adding them when `no-method' is called. We can look at the GOOPS manual
> (goops.info) to see what I mean.
>
> `Method Definition Internals' states that after ensuring the generic and
> creating the method, that the method is added to the generic via the
> generic `add-method!'. If the generics we create are actually subclasses
> of <generic>, we can specify `add-method!' to just keep the method in a
> holding pen of sorts. Which is to say,
>
[code snipped]

> That would delay the work of add-methods! while still keeping the
> generic's symbol around for tab-completion and the like. The only bad
> side is you couldn't query what methods exist on the generic without
> invoking it. The MOP could be extended to turn generic-function-methods
> into a generic function, though.
>
Hey, this looks like a nice idea! IMO introspection into GTK+2
generics a much less needed than a decent load time...

Regards, Andy
-- 
Andreas Rottmann         | address@hidden      | address@hidden | address@hidden
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Packages should build-depend on what they should build-depend.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]