Comment by incrediblers
6 hours ago
My use case is a TUI framework (https://www.incredible.rs/). The setters configure elements in a chain-able manner. I grappled with the rust convention and decided to go the other way. Rational as mentioned.
But this made me think...
> "The getter ought to have a shorter name since it is probably called more frequently"
So i checked. Rough agent driven counts:
https://github.com/ronilan/incredible-flappy 407 setters and 183 getters.
https://github.com/ronilan/rusticon 546 setters and 5 getters
https://github.com/ronilan/shape-sorting 688 setters and 33 getters.
And in a code editor with a lot of ui configurations based on reusable elements 2865 setters and 206 getters.
In reactive apps on state handlers call on setters with state values. No getters involved...
That means those are probably builders and not setters. Do they change an existing object or a newly-constructed or to-be-constructed object?
They are setters. They modify an element after instantiation. Mostly as part of the initial build, but then also in the event closure. Under the hood, a struct with interiorly mutable fields.
This sounds a lot like a builder but the line can be blurry. For a Rust stdlib example, the `process::Command` type is considered a builder even though it is not named "CommandBuilder", and the final operation is spawning a subprocess, not returning some other data.
Gotcha, so in your case, users of the library will set values much more often than read them (since the reading will be done by the TUI framework for display).