Crate status

[pnevyk]

Hi, I am a very happy user of this crate. And before anything else, I will say that the current feature set satisfies all my needs, although sometimes I am thinking that having "self-consuming" setters (fn setter(self, value) -> Self) would be nice.

When reading comments in #84 and #87, I saw comments by @Hoverbear that "the features [this crate] offers and the way it does that are [not] very good". Could you or someone else please elaborate on why? Or perhaps say what to use instead (links would suffice)? I am genuinely curious, I may learn something new.

Since I am opening an issue, I will use it for the question about the plan for this crate. As I said, I am happy with the features that are already available. And I would be fine with knowing that the crate is in maintenance mode and no new, especially bigger features like "self-consuming" setters or support for Option<T> fields, will be merged. But would be small maintenance PRs like fixing small bugs or bumping versions of dependencies accepted?

Might be worth considering to put the answer to the readme, too.

Thanks for this helpful tool!

[Hoverbear]

The project became something I didn't feel ownership of, had several features I never wanted to merge to begin with, and I hadn't used it since one around 2018, so I wasn't the right person to maintain it. I am incredibly glad to have a friend in @jbaublitz who was willing to take this over.

[jbaublitz]

Hi @pnevyk! I'm so sorry for the delay. I'm the new maintainer of this crate, and there are certain features I would be willing to discuss, but my personal feelings about builder patterns in this library is that there are already a number of crates that do this quite well. I'm actually using this crate in another library I maintain, and I've found great success of using this library with a combination of a builder pattern library. I still need to go through the backlog of issues which I intend to do soon and close the ones that I likely won't implement. Other features like Option fields, etc. sound like features I'd be more willing to implement if there's a way to do it. Thanks for reaching out, and I'd be happy to discuss whatever features you're interested in in a separate issue!

[pnevyk]

Hi @jbaublitz, no worries about the delay! I can see how fluent setters feature would overlap with builder pattern libraries, it did not occur to me before, thanks. The difference between hypothetical getset fluent setters and builder pattern libraries (at least those that I saw) would be this:

// getset
let options = MyOptions::default().option_x(value);

// builder pattern
let options = MyOptions::builder().option_x(value).build();

The getset approach feels a bit more lightweight and would be useful in cases where the default value of a struct satisfies most of the situations and only sometimes changing a few options out of many is needed, whereas builder pattern is imho better for situations where one wants to construct a complicated struct where none or only a few fields are optional. But this subtle difference is probably not worth the complexity added to this crate. I am fine with that.

I actually don't have any feature requests, I am a happy user that reaches for this crate whenever I have big structs for which I want to have getters. Thanks for undertaking the maintenance of this crate 👍