Should vtable-goto-object use 'equal instead of 'eq?

Should vtable-goto-object use 'equal instead of 'eq?

[Kristoffer Balintona]

Hello,

I have been using vtable.el for a project of mine and have come across a
bit of an undesirable design choice in vtable, namely, in
vtable-goto-object. Its definition on master is as follows:

        (defun vtable-goto-object (object)
          "Go to OBJECT in the current table.
        Return the position of the object if found, and nil if not."
          (let ((start (point)))
            (vtable-beginning-of-table)
            (save-restriction
              (narrow-to-region (point) (save-excursion (vtable-end-of-table)))
              (if (text-property-search-forward 'vtable-object object #'eq)
                  (progn
                    (forward-line -1)
                    (point))
                (goto-char start)
                nil))))

The relevant line is the one calling text-property-search-forward. I am
wondering whether using equal instead of eq as the predicate is
preferable.

Take the following example. The objects in a given vtable are strings.
For whatever reason, I would like to go to the vtable object
corresponding to the string "foo." I call (vtable-goto-object "foo") but
it returns nil (does nothing). The reason is because vtable-goto-object
uses eq instead of equal. This same situation occurs regardless of what
kind of objec the vtable uses.

As far as I can think of, the only way to productively use
vtable-goto-object is if the objects are stored in e.g. a variable and
referenced within that variable somehow, which is a significant
constraint.

The only case where eq would be desirable is if the vtable contains
duplicate objects, that is, objects which return t on equal but nil on
eq. With these cases in mind, would it be best for vtable-goto-object to
have as a parameter the predicate used by text-property-search-forward
(the default being eq)?

-- 
Best,
Kristoffer

Re: Should vtable-goto-object use 'equal instead of 'eq?

[Adam Porter]

Hi Kristoffer,

> With these cases in mind, would it be best for vtable-goto-object to
> have as a parameter the predicate used by text-property-search-forward
> (the default being eq)?

Personally, I have no objection to making the predicate a parameter, if 
it's necessary to enable a real use case.

I would suggest that a concrete, real-world use case be presented before 
making such a change; I'm not sure if the example you gave is complete 
enough to be one.

AIUI Vtable is intended to present representations of a collection of 
objects.  Strings are objects, of course, and one can have multiple 
references to a string, which should facilitate comparison with EQ. 
Obviously, if a user inputs a new string that matches one in a 
collection, the two strings would not be EQ, but one could easily use, 
e.g. CL-FIND to locate the matching string and use it for 
VTABLE-GOTO-OBJECT.

As well, I could imagine circumstances in which there could be multiple 
objects in a collection which are EQUAL but not EQ.  Of course, you 
didn't suggest changing the default predicate, so that wouldn't be impacted.

Thinking about it further, making the predicate a parameter would allow 
one to pass a bespoke predicate that could do things like look inside 
objects and compare parts of them, which I could imagine being very 
useful.  (So maybe my suggestion about a concrete use case being 
required is too strong, haha.)

So, if no one else objects, I would be in favor of your suggestion being 
implemented.  It should be just a few lines of code and documentation, 
right?  If you submit a bug/patch, feel free to cc me on it.

--Adam