Subject: Re: bug#70664: 29.3; vtable-insert-object cannot insert at top of table

From: Adam Porter <[email-masked]>
Date: Thu, 2 May 2024 23:16:07 -0500

Hi Joost,

On 5/2/24 05:12, Joost Kremers wrote:
> On Thu, May 02 2024, Adam Porter wrote:
>> To be clear, I don't plan to work on this anytime soon.  :)
> 
> No problem. I would kinda like to give it a try myself, but I'm not going to
> make any promises, either. :-)

Of course.  :)

>> Beyond that, IMHO it might be good to write a function with a different
>> signature that would allow more flexibility, e.g.
>>
>> (cl-defun vtable-add (object table &key after before at)
>>    "Add OBJECT to TABLE at specified position.
>> AFTER may be an object after which to insert it; or BEFORE may be an object
>> before which to insert it; or AT may be an integer position at which to insert
>> the object, 0 meaning first and -1 meaning last (only one of these three
>> arguments should be given).")
> 
> I personally don't like the "only one of these three arguments should be given"
> part (what happens if more than one are given?), so perhaps a different
> suggestion:
> 
> (defun vtable-add (object table &optional position before)
>     ...)
> 
> with POSITION being either an object or an integer. If an object, BEFORE being
> non-nil would mean "insert before POSITION", and nil would mean "insert after
> POSITION"). If POSITION is an integer, BEFORE is simply ignored. (With this
> signature, vtable-insert-object could actually be aliased to vtable-add.)
> 
> Though I admit your suggestion has the advantage of explicit keywords.
> 
> Do let me know which approach you prefer, in case I do decide to give it a try.

I generally like to use keywords for clarity when there are more than 
3-4 arguments to a function (also to avoid the "nil nil t" patterns that 
sometimes happens without keywords).

In this case, your idea is slightly less explicit, perhaps requiring 
more careful reading of the docstring, but is more compact, and could 
actually extend the signature of the existing vtable-insert-object 
function, which would seem good.

So, IMHO, I'd suggest applying your idea to the existing 
vtable-insert-object function, i.e. repurposing its existing 
AFTER-OBJECT argument to your new after-object-or-position argument, and 
adding your new before-object-or-position argument (I use those names 
just here for clarity, of course).

(And, BTW, having thought about it further, we should probably keep the 
order of the OBJECT and TABLE arguments as-is in vtable.)

My two cents, anyway.  :)

Thanks,
Adam