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

[Eli Zaretskii]

> From: Robert Cochran <address@hidden>
> Cc: Tom Tromey <address@hidden>,  address@hidden,  address@hidden,  
> address@hidden,  address@hidden
> Date: Sat, 06 Jan 2018 01:37:41 -0800
> 
> Eli Zaretskii <address@hidden> writes:
> 
> >> From: Tom Tromey <address@hidden>
> >> Cc: Paul Eggert <address@hidden>,  Eli Zaretskii <address@hidden>,  
> >> address@hidden,  address@hidden
> >> Date: Fri, 05 Jan 2018 10:58:19 -0700
> >> 
> >> >>>>> "Robert" == Robert Cochran <address@hidden> writes:
> >> 
> >> Robert> IMO, there's not much of a point in wrapping something so simple 
> >> in a
> >> Robert> funcall. I understand that a good compiler will optimize that 
> >> away, but
> >> Robert> that doesn't really fix the code any.
> >> 
> >> Robert> Whatever reason for leaving these has apparently faded into 
> >> history, if
> >> Robert> my past self is to be believed:
> >> 
> >> IIRC those were introduced to support incremental GC.
> >
> > Indeed.  In general, we have similar setters for window, frame, and
> > buffer objects.  Do we want to get rid of all of those?  And if we do,
> > does that mean we abandon all hope for migrating to a more modern GC?
> 
> If the setters in question are tiny wrappers whose entire body is a
> straight assignment to a struct member (like all of the ones I removed
> with this patch), then IMO yes, they should go away.

The value is that these setters allow a much easier switch to a more
modern GC, because most such modern GC methods want to know when an
object was modified.  By removing these setters we in effect say we
don't envision any move to a better GC any time soon.

IOW, a decision to remove those setters need to consider more than
just how thick they are today.  It took a non-trivial amount of effort
at the time to come up with just the right mix of setters, and we've
kept them ever since in the hope that they will be useful to someone
who'd want to work on a better GC for Emacs.

> If these kinds of setters become necessary, for doing the GC bookkeeping
> that you mention for instance, then by all means put them back once they
> do something other that merely set a structure memeber to exactly what
> was passed as a value and nothing more.

Like I said: deciding which setters to put back was a non-trivial job,
which took several iterations.  And who will even remember at that
time that we once had these setters?

I'm not saying I object to the removal of these, just that the
decision at stake is more than what meets the eye.

> My intent is that relatively small changes like this help make the C
> parts of Emacs less intimidating. I've noticed a general social
> perception that the C parts are intimidating, that people generally
> don't want to touch it, and that things are getting to a point where
> there are less and less people who understand the C parts.

My impression is that people find the C parts intimidating because
they are less experienced with C, and therefore feel themselves less
"at home" in a large C program.  And I don't see how a setter whose
name says clearly what it does can possibly intimidate.

But once again, this is a side issue.  If we want to decide that GC
will not change any time soon, I don't object to removing these
setters.  But if we do remove them, then we should also remove the
similar wset_*, fset_*, bset_*, and kset_* functions, and I think we
should remove all of them in the same changeset, to make a future
restoring them easier.

> I feel like the appropriate response then, is to find places like this
> where some of the accidental complexity can be made to go away.

IME, the complexity of the Emacs internals is entirely elsewhere: in
the complex problems the code tries to solve, and in lack of deep
enough background information in the docs/comments that would allow
newcomers to dive fairly quickly into the code and understand what the
code is doing.

So I think the contribution of this change to complexity reduction is
relatively minor.  (But again, I'm not against it.)