Their style is pervasive in Rust, such as in the standard library, so I would personally apply a when-in-rome philosophy. FWIW something like `.text("hello")` I would expect to see in a builder-pattern but not in a setter for an object that's already built.

That being said I don't particularly understand your conception of a method. They are both methods. The getter ought to have a shorter name since it is probably called more frequently and because it inherently has less of an impact -- this goes along with the principle that names that demand attention should be larger and easier to notice.

▲

incrediblers 3 hours ago | parent [-]

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...

▲

afdbcreid 3 hours ago | parent [-]

That means those are probably builders and not setters. Do they change an existing object or a newly-constructed or to-be-constructed object?

▲

incrediblers 3 hours ago | parent [-]

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.

	▲	fwip 23 minutes ago \| parent [-]
		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).