Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: What should have been the term for RAII?

news.ycombinator.com

Post reply on HN
Print view View original

51–60 of 62 posts

Re: Ask HN: What should have been the term for RAII?

#51

Post by jolux »

klyrs wrote: post #44
jolux wrote: post #4

I’m a Rust programmer but I would call it scope-based or scope-bound resource management, a popular alternative term in the C++ community.

> I would call it scope-based or scope-bound resource management RAII isn't about scope, it's about lifetimes that can persist beyond the instantiating scope. More like object-bound resource management.

Scope is a necessary part of it too though. There’s always going to be one owning scope for an object in Rust (unless you’re using Rc) and that scope is responsible for calling the destructor. You can change which scope is responsible by moving it, but scope is still important. Without scope being an implicit part of resource management, you have a feature like try/finally or with in Python.

Re: Ask HN: What should have been the term for RAII?

#52

Post by klyrs »

jolux wrote: post #51
klyrs wrote: post #44

Earlier quoted context omitted.

> I would call it scope-based or scope-bound resource management RAII isn't about scope, it's about lifetimes that can persist beyond the instantiating scope. More like object-bound resource management.

Scope is a necessary part of it too though. There’s always going to be one owning scope for an object in Rust (unless you’re using Rc) and that scope is responsible for calling the destructor. You can change which scope is responsible by moving it, but scope is still important. Without scope being an implicit part of resource management, you have a feature like try/finally or with in Python.

You're still trying to make this about rust without bothering to learn what the C++ users here are talking about. I'm not sure what to tell you.

Re: Ask HN: What should have been the term for RAII?

#54

Post by xedrac »

klyrs wrote: post #44
jolux wrote: post #4

I’m a Rust programmer but I would call it scope-based or scope-bound resource management, a popular alternative term in the C++ community.

> I would call it scope-based or scope-bound resource management RAII isn't about scope, it's about lifetimes that can persist beyond the instantiating scope. More like object-bound resource management.

Many RAII objects really are tied to a simple scope - such as std::lock_guard. So it's not just about persisting beyond the initial scope. I don't recall the word "lifetime" being used in the C++ world before Rust came along. The word "scope" was often used in the same way we talk about lifetimes now. And if you think of the space between an object's constructor and its destructor as a scope, then anything that it owns is tied to its own scope. In this way, calling it "scope-based" is rather intuitive. The only wrinkles would be objects that are tied to multiple scopes (reference counted), and objects that change scopes (move semantics), but even then it's not hard to reason about. Regardless, the term RAII is widely understood, so I'm not sure it needs a new name.

Re: Ask HN: What should have been the term for RAII?

#56

Post by jolux »

klyrs wrote: post #52
jolux wrote: post #51

Earlier quoted context omitted.

Scope is a necessary part of it too though. There’s always going to be one owning scope for an object in Rust (unless you’re using Rc) and that scope is responsible for calling the destructor. You can change which scope is responsible by moving it, but scope is still important. Without scope being an implicit part of resource management, you have a feature like try/finally or with in Python.

You're still trying to make this about rust without bothering to learn what the C++ users here are talking about. I'm not sure what to tell you.

Rust got the concept from C++ and it’s not a C++-specific concept, despite having originated there. You seem to have some fundamental disagreement with what I’m saying that you’ve yet to identify. What does RAII look like without scope, if it’s not about scope? How would RAII work in a dynamically scoped language?

Re: Ask HN: What should have been the term for RAII?

#57

Post by klyrs »

jolux wrote: post #56
klyrs wrote: post #52

Earlier quoted context omitted.

You're still trying to make this about rust without bothering to learn what the C++ users here are talking about. I'm not sure what to tell you.

Rust got the concept from C++ and it’s not a C++-specific concept, despite having originated there. You seem to have some fundamental disagreement with what I’m saying that you’ve yet to identify. What does RAII look like without scope, if it’s not about scope? How would RAII work in a dynamically scoped language?

Specifically, RAII plays really nicely with move semantics -- you can move objects between parent/child scopes, and sometimes that happens transparently (which may be an abomination, or may be heavenly, depending on your worldview). By moving objects (which can be forbidden explicitly or implicitly), you pass their associated resources around, leaving an empty husk to "clean up" when execution hits the end of a scope, which often compiles down to nothing. You need to be mindful of scopes, of course, but RAII isn't about scopes -- it's about being certain that your object is fully capable of satisfying its contracts the moment you've left the constructor.

Re: Ask HN: What should have been the term for RAII?

#58

Post by kazinator »

xedrac wrote: post #54
klyrs wrote: post #44

Earlier quoted context omitted.

> I would call it scope-based or scope-bound resource management RAII isn't about scope, it's about lifetimes that can persist beyond the instantiating scope. More like object-bound resource management.

Many RAII objects really are tied to a simple scope - such as std::lock_guard. So it's not just about persisting beyond the initial scope. I don't recall the word "lifetime" being used in the C++ world before Rust came along. The word "scope" was often used in the same way we talk about lifetimes now. And if you think of the space between an object's constructor and its destructor as a scope, then anything that it ow…

> I don't recall the word "lifetime" being used in the C++ world before Rust came along.

"Lifetime" is a normative term in ISO C. In the 1999 standard, it is given as: "The lifetime of an object is the portion of program execution during which storage is guaranteed to be reserved for it. An object exists, has a constant address, and retains its last-stored value throughout its lifetime." (6.4.2 Storage Durations of Objects)

"Lifetime" appears three times in the Index of the 1988 edition of Compilers: Principles, Techniques and Tools by Aho, Sethi and Ullman (a.k.a. the Red Dragon Book).

Lifetime, of a temporary 480

Lifetime, of an activation 391, 410

Lifetime, of an attribute 320-322, 324-329

Re: Ask HN: What should have been the term for RAII?

#59

Post by xedrac »

kazinator wrote: post #58
xedrac wrote: post #54

Earlier quoted context omitted.

Many RAII objects really are tied to a simple scope - such as std::lock_guard. So it's not just about persisting beyond the initial scope. I don't recall the word "lifetime" being used in the C++ world before Rust came along. The word "scope" was often used in the same way we talk about lifetimes now. And if you think of the space between an object's constructor and its destructor as a scope, then anything that it ow…

> I don't recall the word "lifetime" being used in the C++ world before Rust came along. "Lifetime" is a normative term in ISO C. In the 1999 standard, it is given as: "The lifetime of an object is the portion of program execution during which storage is guaranteed to be reserved for it. An object exists, has a constant address, and retains its last-stored value throughout its lifetime." (6.4.2 Storage Durations of O…

It appears I was simply not exposed to the terminology then. But thanks for the information.

Re: Ask HN: What should have been the term for RAII?

#60

Post by toast0 »

codeflo wrote: post #41

BTW, a lot of people in this thread compare destructors to Java's try-with-resource (similarly, C#'s using), or Go's defer. Here's one important difference: Destructors work in standard data structures. If for whatever reason you want to build a map >, and the map goes out of scope, all files are correctly closed. (Rust's drop semantics work the same way.) That's a lot more work in Java or C#.

Won't Java or C# run the destructor eventually when they GC the equivalent of fstream?

Yes, that means they hang around a lot longer, and that's sometimes problematic, but that's the GC way.

Post reply on HN