Re: fails to build with sbcl 0.9.11

Christophe Rhodes <[email protected]> writes:

> Yes, sorry about that.  Would you mind expanding a bit about the
> interaction of your code with class-finalization?  This is not an area
> I'm comfortable with modifying -- there are very few test cases for
> class finalization in SBCL, and I don't understand all the
> interactions by any means; having more examples might help to
> understand what's going on.

In the code that broke in SBCL 0.9.11 I made the assumption that the
finalization of a class was completed (ie. finalize-inheritance
returned) before any of it's subclasses were finalized, which was the
old behavior in SBCL and still is in CMUCL and CLISP. The workaround was
trivial in this, but I believe the old behavior is the most sane even if
the specification is very vague on this.

> (As I understand it, class finalization is extremely underspecified,
> even by AMOP standards; with the recent changes, SBCL finalizes very
> eagerly: as soon as a class can be finalized, it will be.  By
> contrast, Allegro finalizes very reluctantly; it will only finalize
> when an instance of a class is created -- and won't finalize
> subclasses or even superclasses.  Other implementations are in the
> middle.)

CLISP is in the same category as Allegro, which caused it's own problems
when porting clg. But then I am probably stretching the MOP far beyond
the imagination of those who designed it.

-- 
Espen


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642