Re: [PATCH] src/process.c: remove unnecessary setters

[Robert Cochran]

Here is the link to the head of this thread in the emacs-devel archive:

https://lists.gnu.org/archive/html/emacs-devel/2017-05/msg00857.html

src/process.c contains a few functions that are essentially just setters
that take a struct Lisp_Process and a Lisp_Object and sets a particular
structure member to the Lisp_Object. An example of one that I removed:

#+BEGIN_SRC C
static void
pset_command (struct Lisp_Process *p, Lisp_Object val)
{
  p->command = val;
}
#+END_SRC

IMO, there's not much of a point in wrapping something so simple in a
funcall. I understand that a good compiler will optimize that away, but
that doesn't really fix the code any.

Whatever reason for leaving these has apparently faded into history, if
my past self is to be believed:

>Paul Eggert <address@hidden> writes:
>
>> As I recall those setters and getters were put in for a reason. Have you
>> consulted the development history and emacs-devel logs to see why, and/or
>> contacted whoever added that code?
>
> Not anymore, based on what I see.
>
> With some git-blame history digging, here's what I found:
>
> Dmitry Antipov added the ancestor PVAR macro in 3193acd2 "Use
> INTERNAL_FIELD for processes." on 08/01/2012, and made the struct fields
> use the INTERNAL_FIELD macro in the same commit.
>
> This was split into two macros PGET and PSET in 21238f11 "Separate read
> and write access to Lisp_Object slots of Lisp_Process." on 08/06/2012.
>
> On 08/07/2012, he entirely drops PGET and removes the use of
> INTERNAL_FIELD in 4d2b044c "Drop PGET and revert read access to
> Lisp_Objects slots of Lisp_Process".
>
> Then it was you that removed PSET in favor of individual setters in
> 6a09a33b "* process.h (PSET): Remove.", where the code has sat mostly
> untouched since 08/18/2012 aside from being de-inlined by you in
> b0ab8123d "Prefer plain 'static' to 'static inline'." on 09/30/2012.
>
> Especially given that in 2015, INTERNAL_FIELD was removed (according to
> ChangeLog.2 at any rate), it looks like the reason for the functions
> removed to be abstracted away has long since become irrelevant.

Thanks,
-- 
~Robert Cochran

GPG Fingerprint - BD0C 5F8B 381C 64F0 F3CE  E7B9 EC9A 872C 41B2 77C2