On 14 Aug 2007, at 12:15, Nikodemus Siivola wrote:
Comments and questions more then welcome,
Hm, I have the impression that the interface you suggest is too low-level and too fine-grained. I think something simpler would be sufficient.
Here are some suggestions, as a starting point for brainstorming:
(1) I may want to say that a particular class should not be redefined anymore.
(2) I may want to say that a particular class and all its current subclasses should not be redefined anymore. [Can easily be expressed if we have (1).]
(3) I may want to say that the class hierarchy from a certain class downwards is closed - i.e., it should not be allowed to add more subclasses to that subtree.
While we're at it:
(4) I may want to say that a particular generic function should not be redefined anymore (methods should not be added or removed).
(5) I may want to say that the set of specializers covered by a particular generic function is complete (methods may be redefined, but methods for new specializers shouldn't be acceptable anymore).
I think these are the kinds of things one may want to say because they are semantically meaningful, and at the same time, they should allow implementors to create more efficient code.
Dylan seems to have something like (3) and (4), and maybe (5) (but I don't completely understand the Dylan specification in that regard).
EuLisp seems to have something like (1), (2), (4) and (5).
What's important, I think, is that the interface for sealing should be simple enough that the effects are easily predictable and should avoid potential hard-to-find bugs. I am not convinced that Nikodemus's suggestion is simple enough in that regard.
Tiny CLOS (both the Scheme and the Common Lisp versions) has a different instance structure protocol. I think it should be possible to integrate that new protocol with CLOS without violating the CLOS MOP (but I am not 100% sure), and get some improved efficiency out of it. It seems to me that parts of Nikodemus's suggestion goes in the same direction.
With the current CLOS MOP, sparse instances should be possible: Just add more slots in compute-slots with gensymmed names. Or am I missing something?