> chain-oriented APIs (methods like `fn frob(self) -> Frob`)
What about:
~~~
fn frob(self) -> Frob {
let mut x = self; // not sure if you need `cast::transmute_mut` here
x.thing = foo();
x
}
~~~
That would solve the 'copying' problem.
I was actually considering doing this as a way of initialising an object in a
fluent style:
~~~
let perlin = Perlin::from_seed_str("Kittens")
.with_frequency(2.0)
.with_octaves(3);
~~~
~Brendan
On 22/10/2013, at 9:18 AM, Erick Tryzelaar <[email protected]> wrote:
> In my opinion, there are two main reasons why one would prefer an immutable
> API over a mutable one: aliasing and sharing substructures. Given that unique
> pointers and references have mostly solved the first one, in my opinion we
> should prefer mutable APIs unless the API is going to take advantage of
> structure sharing. I don't think it makes a lot of sense to have immutable
> APIs like this:
>
> fn frob(&mut self) { ... }
> fn frobed(&self) -> Frob { let x = self.clone(); x.frob(); x }
>
> It's a lot more straightforward for the users to write `let y = x.clone();
> y.frob();`, and it protects us from another combinatorial explosion of
> methods.
>
> All that being said, I feel there is an open question on whether or not to
> prefer statement oriented mutable APIs (methods like `fn frob(&mut self)`)
> and chain-oriented APIs (methods like `fn frob(self) -> Frob`). Does anyone
> have a good argument for one over the other?
>
>
>
> On Sat, Oct 19, 2013 at 9:42 AM, Eric Sampson <[email protected]> wrote:
>
> Date: Fri, 18 Oct 2013 10:54:23 -0700
> From: Jeff Petkau <[email protected]>
>
>
>
>
> On my code (disclaimer: only toy projects to learn Rust so far), I've been
> pretty happy with a "mut_" prefix for mutable versions.
>
> newthing = oldthing.push(foo")
> anything.mut_push(foo")
>
> x = bagofun.sort()
> bagosadness.mut_sort()
>
> etc.
>
> Advantages:
> - consistent meaning with the 'mut' keyword.
> - works with pretty much any name.
> - makes mutable versions just a bit uglier than immutable code.
>
> Disadvantages:
> - If an API is inherently mutable, it gets pretty noisy.
> - A bit ugly, probably turns off newcomers.
> - If the compiler warns on ignoring return values, and mutating methods
> return (), then a convention might be unnecessary.
>
> --Jeff
>
>
> What about establishing a convention that mutable methods start with an
> uppercase letter while non-mutating methods start with a lowercase letter? It
> would be lightweight in terms of character count/looks and at the same time
> give mutable methods a slight visual emphasis, which makes sense I think.
>
> I know this convention is already used by Traits, but when I looked through
> some code with the above proposal in mind it would be easy to distinguish
> between these two uses of the same convention due to the differing contexts
> they're used in.
>
> -Eric
>
>
>
>
>
>
> _______________________________________________
> Rust-dev mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/rust-dev
>
>
> _______________________________________________
> Rust-dev mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
