Re: EIEIO: A question about interfaces

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> If you really might use all combinations, then maybe you should rather
>> look at `my-foo-interface` as a separate type where one of its fields
>> might be of type `my-1`, `my-2`, ...
>
> Probably, yes.
>
> But again: originally, all objects of the hierarchy would match the
> method specifier `my-1`, objects of the new type would not, which may
> cause (big) trouble.
>
> I could make the new type to inherit from the interface class and
> additionally also from my-1 to avoid this problem, but that would be
> really weird, because when the my-1 base class would have default
> field(s), they would exist twice in these kinds of objects.  Note that
> in my (hypothetical) scenario, I have no control how the `my-1`
> subclasses are defined, say they are built in or provided by a library I
> don't author, and also no way to change the code where the `my-1`
> specifiers are used.
>
> A cool solution would be if `make-instance' would allow to specify
> multiple classes, or if I could alter an already existing object that is
> an instance of my-17 (which stands for an arbitrary subclass of my-1) so
> that is also becomes an instance of `my-foo-interface`, or at least
> create a new object which is equal to the original object modulo my-17
> behavior but is also an instance of the interface, in an ad hoc manner.
> `class-of' could return a tuple of classes representing the ad-hoc
> class.  Everything else would behave as if I had explicitly created a
> class for this kind of object inheriting from the according parent
> classes.

This looks to me like you might be able to define your own
specializer/generalizer which fires t when it sees an object that fits a
certain criteria. You wouldn't be able to affect the existing codebase
you're working with, but you could certainly do this for your own code.