Re: eieio-base patch to support EDE project loading

[Eric Ludlam <eric@siege-engine.com>]

On 10/4/19 4:45 PM, Stefan Monnier wrote:
>> Without that list of superclasses, `child-of-class-p' fails.  Since having
>> the superclass list in autoloads is a non-starter, this patch will
>> un-autoload classes found in the file being read before the call to
>> `child-of-class-p'.
> 
> Looks good, but I felt like those un-autoloads scattered around felt
> a bit haphazard (with tests slightly different each time), so I suggest
> the patch below instead, WDYT (which also moves the un-autoload to
> child-of-class-p so it applies not just to
> eieio-persistent-validate/fix-slot-value but to all users of
> child-of-class-p).

Patch looks like a good idea to me.  I was worried about overhead of 
always checking and un-autoloading, but this patch seems to deal with 
that nicely.

The original problem arose when trying to identify the class parents. 
Perhaps using eieio--full-class-object in eieio-class-parents would cast 
a slightly wider net?

> 
>> It would be better to store the superclasses in the autoload declaration so
>> that extensible class hierarchies can be more dynamically loaded without
>> internal checks with un-autoload, but I don't know enough about how the new
>> version of eieio works to provide that patch.
> 
> It would allow child-of-class-p to be computed without loading the
> class, hence a bit more laziness, but I'm wondering how often it would
> make a real difference: how likely are you to use child-of-class-p
> without either already having an instance of that class or being right
> about to build such an instance?

I agree.  The patch solves the problem in a more pragmatic way.

> Can you test the patch below before I push it?

It works great.  Thanks for looking into it!

Eric