mop:finalize-inheritance?
Peter Seibel
MOP:CLASS-SLOTS on a class but get an error about inheritance not
being finalized. So it seems that I can just call FINALIZE-INHERITANCE
first and I'm okay. But that seems strange and kludgy. Is there a
reason CLASS-SLOTS doesn't just go ahead and call it for me? Is there
any danger of me calling it too soon?
-Peter
--
Peter Seibel * pe...@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Pascal Costanza
> When is it safe to call FINALIZE-INHERITANCE? I want to call
> MOP:CLASS-SLOTS on a class but get an error about inheritance not
> being finalized. So it seems that I can just call FINALIZE-INHERITANCE
> first and I'm okay. But that seems strange and kludgy. Is there a
> reason CLASS-SLOTS doesn't just go ahead and call it for me? Is there
> any danger of me calling it too soon?
I don't really understand that restriction either. From the various MOPs
I have seen, only Allegro Common Lisp seems to take "advantage" of the
fact that finalize-inheritance doesn't need to be implicitly called when
it would make sense.
In general, it is safe to call finalize-inheritance when you can ensure
that all the superclasses of a class exist (i.e., they are not forward
referenced), usually immediately after this class has been defined. I
don't think subsequent calls to finalize-inheritance have any negative
effect since it can check class-finalized-p and just silently do nothing
when the latter yields t.
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
Christophe Rhodes
> When is it safe to call FINALIZE-INHERITANCE? I want to call
> MOP:CLASS-SLOTS on a class but get an error about inheritance not
> being finalized. So it seems that I can just call FINALIZE-INHERITANCE
> first and I'm okay. But that seems strange and kludgy. Is there a
> reason CLASS-SLOTS doesn't just go ahead and call it for me? Is there
> any danger of me calling it too soon?
I don't believe that it's legal or sensible to redefine a finalized
class such that it acquires a forward-referenced supercless; such a
redefinition does make sense for one that has not been finalized. In
such cases, something calling finalize-inheritance "for you" might be
suboptimal.
Christophe
Pascal Costanza
> I don't think subsequent calls to finalize-inheritance have any negative
> effect since it can check class-finalized-p and just silently do nothing
> when the latter yields t.
BTW, this means that you can just call finalize-inheritance in portable
programs, and don't need to conditionalize your code for this case.
Steven M. Haflich
> When is it safe to call FINALIZE-INHERITANCE? I want to call
> MOP:CLASS-SLOTS on a class but get an error about inheritance not
> being finalized. So it seems that I can just call FINALIZE-INHERITANCE
> first and I'm okay. But that seems strange and kludgy. Is there a
> reason CLASS-SLOTS doesn't just go ahead and call it for me? Is there
> any danger of me calling it too soon?
Peter -- Obviously, a programmer can infer what you mean by this
question, but the question statement is imprecise which allows potential
answers to magnify the imprecision. You are using the term "safe" in a
way that is different from the usage in the ANS, and I believe the term
"legal" doesn't appear at all in the ANS.
Consider this rhetorical question: Is it _legal_ to execute (car 22/7)
in safe code?
I'll have more to say about your real question in response to later
postings in the thread.
Steven M. Haflich
> I don't really understand that restriction either. From the various MOPs
> I have seen, only Allegro Common Lisp seems to take "advantage" of the
> fact that finalize-inheritance doesn't need to be implicitly called when
> it would make sense.
>
> In general, it is safe to call finalize-inheritance when you can ensure
> that all the superclasses of a class exist (i.e., they are not forward
> referenced), usually immediately after this class has been defined. I
> don't think subsequent calls to finalize-inheritance have any negative
> effect since it can check class-finalized-p and just silently do nothing
> when the latter yields t.
It is not actually not "safe" to call finalize-inheritance because it is
easy to define a "mixin" class using the MOP that will signal error if
there is an attempt to finalize (or instantiate) it. So calling
finalize-inheritance promiscuously is probably not a good idea unless
you know the intentions of the author of the class(es).
To screw into a more-difficult screw case, I believe one could write a
metaclass that handles finalization with not-yet-defined
foward-reference-classes, perhaps by simply ignoring forward-reference
classes and omitting them from the CPL. This requires specialkizing
several protocols of the MOP, but (without really working out the
details) I don't see any obvious impossibilities.
There is a hidden moral in my fussy and opaque replies tio this thread:
Very often questions about the MOP are posed with regard to the
standard behavior of the standard metaobject classes. These are useful
and informative questions, of course, but they may miss the obvious
truth that the MOP is powerful eought to allow redefinition of behavior
for custom metaobject classes where the "usual" rules no longer apply.
In closed systems this might be OK, but don't write programming tools
that might violate the legitimate assumptions made by other programming
tools -- otherwise, your tools might not compose othogonally with mine!
Pascal Costanza
> Pascal Costanza wrote:
>
>> I don't really understand that restriction either. From the various
>> MOPs I have seen, only Allegro Common Lisp seems to take "advantage"
>> of the fact that finalize-inheritance doesn't need to be implicitly
>> called when it would make sense.
>>
>> In general, it is safe to call finalize-inheritance when you can
>> ensure that all the superclasses of a class exist (i.e., they are not
>> forward referenced), usually immediately after this class has been
>> defined. I don't think subsequent calls to finalize-inheritance have
>> any negative effect since it can check class-finalized-p and just
>> silently do nothing when the latter yields t.
>
> It is not actually not "safe" to call finalize-inheritance because it is
> easy to define a "mixin" class using the MOP that will signal error if
> there is an attempt to finalize (or instantiate) it. So calling
> finalize-inheritance promiscuously is probably not a good idea unless
> you know the intentions of the author of the class(es).
OK, what I had in mind was that it's safe to call finalize-inheritance
for your own classes, something along these lines:
(defclass my-class (...)
(...)
...)
(finalize-inheritance (find-class 'my-class))
I still think it's safe (you know what I mean ;) to do that when you
know about the superclasses and the metaclasses being used.
However, I have admittedly not been aware of possible problems with
calling finalize-inheritance on other classes (those that you haven't
defined yourself). So thanks to you and Christophe for pointing this out.