On Tue, Nov 3, 2015 at 7:12 PM, Dmitry Gutov <
dgutov@yandex.ru> wrote:
> Maybe they would, but you already understand that it's not a realistic example. Anything
> they might want to store in the properties, they can store inside their xref-derived instance.
Yup. Though, there's this comment at the beginning of xref.el:
;; Each identifier must be represented as a string. Implementers can
;; use string properties to store additional information about the
;; identifier, [...]
> When we add a new generic function, it's good to document exactly what is expected
> of its implementations. Which is hard to do without knowing use cases.
I've stopped arguing for a generic comparison function (I've read the rest of the thread and it's obvious that Stephen and you don't consider it useful). But as a general comment, I disagree with this. A generic function, in most languages or frameworks that define interfaces, do not document "exactly" what is expected of the implementations. They document the behavior in general terms. Which in this case would be: "Compare two xref-location items and return non-nil if they are considered equal, nil otherwise." That's *all* a generic comparison function for xref-location should need to document.
> Why *-tests.el? Canonicalization should happen inside the constructor function, if anywhere. E.g. inside xref-make-file-location and xref-make-elisp-location.
I though "solved as above" meant Stephen's fix for this particular bug.