Rewrite RAII pattern article to adapt to OBRM terminology

[9SMTM6]

As the relevant section points out RAII isn't a great name for the concept. Rust actually has its own name for the concept, Ownership Based Resource Management, which I find vastly superior.

Of course we should keep references to RAII to make this easy to find and to ease adaption, but I'd like to switch to primarily OBRM terminology in that section.

I'll probably get to doing that over the weekend, but anyone may feel free to do that themselfes. This issue was created to ensure this eventually gets resolved, and to ensure that the maintainers will accept such a PR.

[9SMTM6]

Nomicon uses OBRM:

https://doc.rust-lang.org/nomicon/obrm.html

Relevant page in this project:

https://rust-unofficial.github.io/patterns/patterns/behavioural/RAII.html

[simonsan]

We might want to add a link to the page you brought up stating that it is a different term. Renaming is not the way to go imho as RAII is a commonly used term that is also known to other programmers which makes it possible to find this article in the first place. (CC: https://github.com/rust-lang/rust-by-example/issues/1624 )

[neithernut]

Or at least add a short paragraph explaining that it's called RAII in other languages/in general. (including said link or paraphrasing the rationale).

[simonsan]

Or at least add a short paragraph explaining that it's called RAII in other languages/in general. (including said link or paraphrasing the rationale).

Yes, that seems reasonable.

[9SMTM6]

There's different groups we could want to target with that page. As it it, that page is combining the bad parts of the target groups I can think of.

If we want to ease the understanding of programmers coming from C++, then yeah, the page quite openly uses that terminology, but these people already know patterns for RAII, and the page does NOT make a good job of explaining the subtle differences between Rust and C++, like destructive move, and how that might apply to patterns.

If we want to ease understanding of completely new people then the current terminology makes things hard to understand. EVEN the linked page on cppreference predominantly uses Rust terminology (they implicitly explain ownership, also using terms like lifetime).

And OBRM is, as far as I understand it, the official Rust terminology.

As I said in the opening post, I want to keep RAII terminology present to address your point @simonsan, we could also keep it in the title, but if I an going to update the page I would use Rust terminology as a default. If that's not what the maintainers want then perhaps someone else should do it how it's desired.

[simonsan]

I think it would be interesting to read your proposal as a PR, then we can work out together the fixes and discuss the things at place.

[neithernut]

As I said in the opening post, I want to keep RAII terminology present to address your point @simonsan, we could also keep it in the title, but if I an going to update the page I would use Rust terminology as a default. If that's not what the maintainers want then perhaps someone else should do it how it's desired.

Imo RAII doesn't need to appear in the title at all (and, in fact, shouldn't if we switch to OBRM) as long as the page pops up in a search for "RAII". A short note that the concept is also known as/identical in its execution to RAII should be sufficient. However, it's necessary to have that small note in order to avoid confusion.

Maybe I'm old but I distinctively remember people, including myself, going "did they just reinvent the wheel and gave it a different name in order to make it sound like it didn't exist elsewhere decades ago?" on certain occasions Java-folks talked about "new and shiny" language features. Such an impression could easily be mitigated with two short sentences mentioning "RAII" and, maybe, its broad (semantically) differences.

But as @simonsan already noted, it's easier to comment on a PR than to lay out every little detail we'd want to see from a change.

[9SMTM6]

Perhaps we could revert to the old title of this Issue or give another fitting one, as it stands the title doesnt fit with my opening comment, and doesnt reflect what I've done in my PR.

Otherwise, discussions should continue in the PR I guess?