From: Tim Bradshaw
Subject: required-x and protocols in CLOS
Date:
Message-ID: <nkjitp0w8b7.fsf@tfeb.org>
Flavors used to have a feature where you could say when defining a
flavor that any non-abstract flavor that inherited from this would
have to inherit from various other things, and possibly would have to
implement various methods too.
I forget the exact details unfortunately (someone will know!), but the
basic idea behind it was that you could (partly) enforce a requirement
that a (sub)class should play a role in some protocol. This is kind
of similar to what Java does with its interface definitions.
Obviously this kind of thing is much easier with a system which is
basically message-passing, because then it's easy to ask `does this
class have a method for this GF?', which is a much harder question to
ask in a more complex system like CLOS.
I'd like to know if anyone has done anything like this for CLOS.
Obviously a *full* solution, in terms of providing a definition of
what a protocol is, and what role a class plays in it and so on, is
very hard, but a solution which didn't address the whole problem but
only parts of it would still bne interesting (to me anyway).
The kinds of assertions I'd like to be able to make are something like:
Any instantiable subclass of this class must have a method for
the FOO gf with it as the second argument.
If an instantiable subclass of this class overrides FOO it
must also override BAR
(the terminology here is obviously terrible: classes don't define
methods in CLOS).
I'm not after a `standards-quality' solution as I think this is a *very*
hard problem in general, but anything that let me check some kinds of
assertions semi-mechanically would be a win, and I'd be interested if
anyone has done anything along these lines before I try and implement
(more of) a solution myself. I kind of expect any reasonable
solution would use the MOP.
Thanks
--tim
(Incidentally, the simplest part of this -- abstract classes for which
MAKE-INSTANCE signals an error -- is *very* easy using the MOP. I
have a version of these which works in most or all of the serious
Lisps which I could make available, though it's a tiny amount of
code.)
Tim Bradshaw wrote:
> I'm not after a `standards-quality' solution as I think this is a
> *very* hard problem in general, but anything that let me check some
> kinds of assertions semi-mechanically would be a win, and I'd be > interested if anyone has done anything along these lines before I try
> and implement (more of) a solution myself. I kind of expect any
> reasonable solution would use the MOP.
I don't know Flavors, but here are some general (maybe too general)
ideas:
A possible point of assertion checking would be a method hooked onto
finalize-inheritance, giving you a strong enforcement (can't instantiate
without class finalization) and in most cases you have encountered all
method definitions before instantiation (if not, you may get a false
alarm, erring on the conservative side).
If you create a specialized metaclass below standard-class, you may
define class definition slots that would carry the assertion inside a
(modified) defclass macro.
To actually look for specialized methods, you could use the gf and
method reader functions of MOP.
All these don't help a bit removing the question marks around the
concept itself. May I wonder how your requirements have arisen?
Robert
From: Tim Bradshaw
Subject: Re: required-x and protocols in CLOS
Date:
Message-ID: <nkjlmtvi0zv.fsf@tfeb.org>
Robert Monfera <·······@fisec.com> writes:
>
> A possible point of assertion checking would be a method hooked onto
> finalize-inheritance, giving you a strong enforcement (can't instantiate
> without class finalization) and in most cases you have encountered all
> method definitions before instantiation (if not, you may get a false
> alarm, erring on the conservative side).
>
> If you create a specialized metaclass below standard-class, you may
> define class definition slots that would carry the assertion inside a
> (modified) defclass macro.
>
Yes, these are the kinds of things I'm thinking of. One of the
problems is that you can't really get a good enough hook into DEFCLASS
without redefining it at the macro level -- it would be nice if you
could somehow get at the option processing, but things like the
ENSURE-CLASS* functions aren't the right place.
> All these don't help a bit removing the question marks around the
> concept itself. May I wonder how your requirements have arisen?
Because I want to do some kind of mechanical protocol enforcement --
for instance `if you define a subclass of this class it must also
inherit from this other class' or `if you override this method you
must also override this other method'.
--tim