Hi,

Sometimes, you know better ways to answer questions that have come up during a talk after you've returned home. So in this case.

There was a question wrt to the LispWorks MOP and its introspection capabilities. It seems to me now that I have left the impression that one cannot inspect a class for its (declared or effective) slots. This is not true. In fact, all the slots that you define as usual in a defclass form are still available as slot-definition objects and can be queried, and so on.

The only difference between the AMOP specification and the LispWorks MOP in this regard is that the slot-xxx-using-class generic functions are passed a slot-definition metaobject as the third parameter in AMOP, but the slot name in LispWorks.

Of course, one cannot query a class for the slots that happen to have been added to single instances after they have been created in the hash-table-based classes - after all, the purpose of those is to add potentially unknown slots after the fact. However, it's possible a) to query single instances for slots that they know about and b) to add more functionality to the hash-table-based class so that it keeps track of all the slots that have been added to instances thereof, and then it would be possible to query that (potentially growing) set. You will just not be able to query them as slot-definition metaobjects, that's all.

On a different note: There was one remark about slot-makunbound-using-class being too liberal with regard to an object's hash table. We have been drawn into a discussion whether one way or the other is better. However, what I have been missing and is more important here is the fact that we don't have to agree here. The cool thing about the MOP is that everyone can have the object model that suits them most for the given task at hand. I think it's important to stress this once more because it takes a little getting used to the fact that there is no one single right way to do things.

Pascal