lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On Mon, Nov 23, 2015 at 2:16 PM, Philipp Janda <> wrote:
> Am 23.11.2015 um 22:46 schröbte Coda Highland:
>> On Mon, Nov 23, 2015 at 1:25 PM, Philipp Janda <> wrote:
>>> That's nonsense. Many static languages don't have RAII.
>>> Joking aside, so far I have not found a better tool for generic resource
>>> management than RAII. Advantages of RAII over finally/using/with: You
>>> need
>>> only one language feature (destructors) instead of two (finalizers and
>>> finally), so the language is less complex/bloated (see C++!). And more
>>> importantly you only write your resource management code once and not
>>> multiple times scattered around in your source code.
>> That's a fallacious claim. You DO need two language features to
>> implement RAII -- destructors and deterministic cleanup. Destructors
>> with nondeterministic cleanup is exactly what Lua has right now with
>> the __gc metamethod.
> If you want to count deterministic cleanup you also have to count the
> garbage collector, so it's two features compared to three.

No, you don't have to count the garbage collector, because the other
scheme doesn't REQUIRE a garbage collector. You could implement it
using whatever memory management / cleanup scheme you want, including
a deterministic one. (After all, C++ has finally; alternatively,
refcounting is deterministic.) But you can't implement RAII unless you
have deterministic cleanup.

>> Saying that C++ is less complex/bloated is also a pretty flimsy claim,
>> considering that the typical criticism of C++ is that it's
>> overengineered and complicated, and that the typical praise of Lua is
>> its minimalism.
> The C++ part was a joke (obviously, I thought). I'm aware that C++ is
> considered complex and bloated (and rightly so). But RAII is not the problem
> there (that part was meant seriously).

The way I read it is that RAII is less complex/bloated than finally
clauses because it only requires one language feature instead of two,
and then you called out C++ as if in support of that point; I didn't
perceive humorous intent in highlighting C++ there.

>> And as for where resource management goes, C++ code involves writing
>> resource management ALL OVER THE PLACE. You have to pay attention to
>> scoping and you have to either manually free heap-allocated memory or
>> explicitly use a container that does it for you. That's a far cry from
>> keeping the code centralized.
> Manually free'ing heap-allocated memory is *not* RAII. To get the benefits
> you actually have to use it. C++ doesn't force you to use RAII (and it
> probably shouldn't -- it's too low-level for that), so you might be right
> about resource management in C++ code, but I still think I'm right about
> resource management with RAII.

You're right that RAII allows you to avoid littering your code with
cleanup boilerplate -- proper use of RAII is a lot better than try {
open(); } finally { close(); } all over the place. But RAII doesn't
magically free you from cleanup boilerplate; it just moves it from the
point of use to the point of declaration. Every class you create has
to explicitly include its own cleanup code, and there are cases
(particularly when there are interdependencies between states) where
black-boxed RAII causes headaches. C++ eventually realized this
headache and added a finally construct to the language, because
sometimes cleaning up requires more than just calling destructors in
reverse order.

This is why I say that if I had to choose just ONE of the two, I'd
prefer finally over deterministic destructors -- while it's possible
to implement either in terms of the other, the headache of dealing
with the cases that are less-naturally expressed using destructors
outweighs the code-brevity benefit of RAII.

In my ideal language, I have both.

/s/ Adam