[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: eieio-base patch to support EDE project loading

From: Eric Ludlam
Subject: Re: eieio-base patch to support EDE project loading
Date: Sun, 6 Oct 2019 08:18:08 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0

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

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

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!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]