Comment by afdbcreid
8 hours ago
That means those are probably builders and not setters. Do they change an existing object or a newly-constructed or to-be-constructed object?
8 hours ago
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.
What I was saying is that I think a "flipped pattern" where anything that sets something sometime somewhere is the word and anything that reads is a get_* makes this fine distinction unnecessary... and that makes life easier... I came to Rust from JS where one can overload methods... I understand from other comments that the set_* convention may have arrived from C++... In any case, consistency I think beats specifics.
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).