[closer-devel] C2MOP and class-prototype

[Slava Akhmechet]

> This doesn't have anything to do with how AMOP is interpreted - it's
> simply not specified.
Ok. I just disagree with the following reasoning:

> According to the CLOS MOP specification, the behavior of
> class-prototype on instances of built-in-class is undefined. (The
> entry for class-prototype states that it signals an error if the
> class has not been finalized yet, but there is no method specified
> for finalize-inheritance that is applicable for built-in-class.)
As I understand it, the purpose of signalling an error if the class
has not been finalized is to avoid tricky situations where you try to
create a prototype of a partially specified class - an operation that
doesn't make sense. I don't think this reasoning applies to
build-in-class - there is no finalize-inheritance specialization
because built in classes can be considered finalized at the time
application code is evaluated. What would be the purpose of enforcing
this logic on built in classes? If anything, it causes unintuitive
behavior and makes class-prototype less useful without a good reason
to do so. It isn't very hard to return some template values for
built in classes and it seems like there are no cases where doing so
would cause undesireable behavior.

> On the other hand, I agree that this is a border case, and may be a
> good starting point for actually introducing improvements to the
> CLOS MOP - which is something I have in mind for a kind of Closer to
> MOP 2.0 anyway, only that I don't know whether I will ever get
> around to it (so don't hold your breath ;).
One option is to introduce a flag that will control C2MOP's
behavior. People could configure the library to leave such cases up to
discretion of their implementation or choose a more strict mechanism
that would help them to avoid depending on non-portable features.

> I suspect that a well defined list of these areas could be made. It
> would be nice if programmers could specify (by project (perhaps in
> an ASDF property of their system definition)) which things are OK
> and which things are not.
Perhaps this could be combined with the general configuration flag I
propose above. People would say whether they want strict or relaxed
behavior and would then be able to override particular cases as
necessary.

-- 
Regards,
Slava Akhmechet.