3 ms·

The discussion of how borrowing impacts encapsulation, abstraction with private methods, and the observer pattern was informative and interesting.

w4tson 9y ago
I found it useful. I think there’s a missing guide out there for people like myself who have an OO background, are looking to write some rust but can’t reconcile the borrow-checker with how they normally design software
- juanpotato 9y ago
  https://doc.rust-lang.org/nightly/book/second-edition/ch04-01-what-is-ownership.html https://doc.rust-lang.org/nightly/book/second-edition/ch04-0... try this
deleted 9y ago
[deleted]
moomin 9y ago
It's interesting, but overstated. It's more a description of how some Java patterns don't translate. For instance, the first example "encapsulation" demonstrates exactly no encapsulation. In general terms although sometimes you need to do things like this, shared mutable state is something you should be avoiding in any language and you should thank Rust for making it harder on you.
- solidsnack9000 9y ago
  > ...the first example "encapsulation" demonstrates exactly no encapsulation. It demonstrates a kind of getter, but a weird one since it returns a mutable field. These are not the most encapsulated thing.
oconnor663 9y ago
I think the part where they're trying to abstract out a `content` method could be made to work by adding braces, so that the `&self` borrow goes away earlier than the end of the function. I think "nonlexical lifetimes" are also going to make more cases like that work automatically without braces soon.
- bluejekyll 9y ago
  Yes. I use that often. It’s ugly though, and lexical lifetimes should help fix this.
- rom1v 9y ago
  > I think the part where they're trying to abstract out a `content` method could be made to work by adding braces, so that the `&self` borrow goes away earlier than the end of the function. Not in that case. It helps when dropping a borrow earlier avoids to violate the borrowing rules, like in this case: let mut a = [0; 20]; { let b = &mut a[2..4]; } let c = &mut a[6..8]; In the example from the blog post, content borrows the whole struct, and you can't drop the borrow earlier since it is used in the next line.
  - oconnor663 9y ago
    Right, you'd have to split up the following line so that `sum` is computed inside the block but assigned after it.

w4tson 9y ago

I found it useful. I think there’s a missing guide out there for people like myself who have an OO background, are looking to write some rust but can’t reconcile the borrow-checker with how they normally design software

juanpotato 9y ago
https://doc.rust-lang.org/nightly/book/second-edition/ch04-01-what-is-ownership.html https://doc.rust-lang.org/nightly/book/second-edition/ch04-0... try this

deleted 9y ago

[deleted]

moomin 9y ago

It's interesting, but overstated. It's more a description of how some Java patterns don't translate. For instance, the first example "encapsulation" demonstrates exactly no encapsulation. In general terms although sometimes you need to do things like this, shared mutable state is something you should be avoiding in any language and you should thank Rust for making it harder on you.

solidsnack9000 9y ago
> ...the first example "encapsulation" demonstrates exactly no encapsulation. It demonstrates a kind of getter, but a weird one since it returns a mutable field. These are not the most encapsulated thing.

oconnor663 9y ago

I think the part where they're trying to abstract out a `content` method could be made to work by adding braces, so that the `&self` borrow goes away earlier than the end of the function. I think "nonlexical lifetimes" are also going to make more cases like that work automatically without braces soon.

bluejekyll 9y ago
Yes. I use that often. It’s ugly though, and lexical lifetimes should help fix this.
rom1v 9y ago
> I think the part where they're trying to abstract out a `content` method could be made to work by adding braces, so that the `&self` borrow goes away earlier than the end of the function. Not in that case. It helps when dropping a borrow earlier avoids to violate the borrowing rules, like in this case: let mut a = [0; 20]; { let b = &mut a[2..4]; } let c = &mut a[6..8]; In the example from the blog post, content borrows the whole struct, and you can't drop the borrow earlier since it is used in the next line.
- oconnor663 9y ago
  Right, you'd have to split up the following line so that `sum` is computed inside the block but assigned after it.