Sure, not trying to start an argument about whether this particular case is justified – my point here is that the example and its comment demonstrates how “private” is about developer control (even if that is often a point of contention).
Some design philosophies would say “never make anything private” – maximum tinkering. I’m a tinkerer, so I’m not against that. However everything that is public is the API – the programming interface – and small teams with huge APIs may have pragmatic reasons for wanting to keep the interface as small as possible.
There are also some design patterns and philosophies that teach people to make variables / properties private always or almost-always. In OOP, one big one is encapsulation, which in Java might mean handling a variable with getters and setters. So
public String sketchPath() = good,
public String sketchpath = bad (according to that design logic). However, these can be guidelines, not laws. Processing is sometimes one way, sometimes another. For example, PVector exposes x and y directly (
vec.getX()), but Table does not expose its internal rows array as
A standard way to route around anything private in open source is to fork the codebase, change the field(s) to public, and build. It can be a pain, but then you have a PDE with any exposed internals you like – although only for you.