Re: master 1d9d07fb00e 3/3: (cl--typeof-types): Rework to fix some regressions

[Andrea Corallo]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>>> I'm not sure I understand.  Is some code relying on the "order" of the
>>>>> supertypes?  Are these the regression you are mentioning?
>>>>> Must say I'm surprised supertypes can have an "order" in first place.
>>> Hmm... a lot of what I've been talking about in this thread is about the
>>> order of parents in `cl--typeof-types`, so yes, the order is important.
>>> It determines the priority between methods.
>> I'm asking because I'd personally consider any program relying on of the
>> parent order just buggy.
>
> Such dependencies are rare, indeed.  They're rare enough that I wouldn't
> have enough intuition to judge whether they reflect bugs or not.  In any
> case CLOS wants it, and I see no reason to do otherwise: the cl-generic
> code needs to order the methods according to some criteria, so I prefer
> to document that we do it like CLOS than to make it "undefined" (it'd be
> extra work to try and detect such undefined cases, on top of that, so
> instead we'd get "some arbitrary order" (like we have now) which we'd
> have to preserve to avoid breaking backward compatibility: might as well
> make this arbitrary order somewhat meaningful 🙂).
>
>>>> Also, this commit makes etc/syncdoc-type-hierarchy.el not functional and
>>>> our doc out of sync (it removes the comment asking to run
>>>> etc/syncdoc-type-hierarchy.el when changing 'cl--type-hierarchy' as well
>>>> 🙁).
>>>
>>> Duh, thanks for point it out, I'll update the code accordingly.
>>
>> Thanks no rush,
>
> Done.
>
>> (I myself still have to commit the Makefile magic that
>> installs syncdoc-type-hierarchy output).
>
> Haven't touched that, sorry.

Np was in my todo already, should be done now.

PS the DAG looks pretty cool now 🙂, I'm wondering tho if we should show
as well types like transient*, which don't come preloaded.

  Andrea