Now that the `AudioUnit` type is not a builder type, perhaps use "getters" and "setters" for clarity.

[mitchmindtree]

Might make sense to rename the following:

• render_callback -> set_render_callback
• sample_rate -> get_sample_rate
• stream_format -> get_stream_format

[yupferris]

I can't remember where I saw it, but I remember seeing a library that made me feel like idiomatic Rust would use the set_ prefix for setters, and no prefix for getters. So right off the bat I agree with render_callback -> set_render_callback, but I'd like to see what the norm is for getters first.

[mitchmindtree]

Yeah I know what you mean! I remember feeling similarly at one point. More recently however, I've been trying to use the following idioms:

• .foo(self) for builder methods, I.e. Bar::new().foo()
• .get_foo(&self) where we borrow self immutably to retrieve some value
• .set_foo(&mut self) where we borrow self mutably to set some value

CPAL seems to use getters (here and here).

Perhaps setters and getters might make sense in these cases as the APIs are quite procedural/imperative.

Thoughts?

[yupferris]

The pattern for builder methods you mention is best I think; there's no contention so it's just the shortest name possible.

For getters/setters I still have a hard time deciding, even though CPAL does it with prefixes for both.

I did a search in std for "get", and basically found a bunch of get and get_mut functions; no getters for specific properties.

I searched for "set", however, and came up with a few examples of properties that are exposed this way:

• Vec::len / Vec::set_len
• env::current_dir / env::set_current_dir
• env::var / env::set_var

Beyond that, all I could find was this answer from stackoverflow from a year ago: http://stackoverflow.com/questions/26643626/custom-getters-and-setters-in-a-struct?answertab=votes#tab-top

I opened a thread about it in the users forum; might be interesting to see what other people say.

[mitchmindtree]

Yeah good idea 👍 I'm currently addressing some of the minor issues in the AudioUnit API, but I'll leave this names as they are for now.

[mitchmindtree]

Seems like foo(&self) and set_foo(&mut self) is the way to go!

[yupferris]

For others reading: this RFC is the deciding factor there.

As a bonus, I found an article on the builder pattern which affirms your suggestion for builders :)

[mitchmindtree]

I think it's safe to say that "getters" might only be necessary for the case where some builder method might conflict with some getter method, i.e. sample_rate(self) -> Self vs sample_rate(&self) -> SR.