3 ms·

This is not really a problem in zig. If you really need a destructor, write a .deinit() function in your struct, and call that. For your case with mocks (note

This is not really a problem in zig. If you really need a destructor, write a .deinit() function in your struct, and call that. For your case with mocks (note mock as a noun, not a verb, which is a bit of an antipattern anyways, see: http://blog.plataformatec.com.br/2015/10/mocks-and-explicit-contracts/ http://blog.plataformatec.com.br/2015/10/mocks-and-explicit-...). That aside: Go doesn't have generics so you can't really do this, but in the case of zig, your function would be parametrized on the type, so you would issue it a struct to be shared by the tests that has the common initialization upfront, make_ functions that return the pre-initialized stuff, followed by running the function, followed by no-op deinits, followed by whatever forensics you'd like to run later.

Arnavion 5y ago
>This is not really a problem in zig. If you really need a destructor, write a .deinit() function in your struct, and call that. This is missing the point. The point of a destructor is that it runs automatically. .deinit() is the same as the three cleanup_*()s in my example and thus has the same problems. >but in the case of zig, your function would be parametrized on the type, so you would issue it a struct to be shared by the tests that has the common initialization upfront The third example in my post shows why this is inadequate.
- dnautics 5y ago
  Then im not really sure what your point is, because I've written zig code that reuses code in a similar way to what you are talking about, with three different forms of parallelism calling into some common runner code each of which has different needs for resource cleanup times (single threaded, cooperative, and independent parallelism). It wasn't a problem. Have you tried doing what you propose in zig? Ultimately, the only difference between a .deinit() and a destructor is that one is explicit and the other is not. There are cases where you can easily make a mistake for both an explicit destructor and an implicit destructor.

Arnavion 5y ago

>This is not really a problem in zig. If you really need a destructor, write a .deinit() function in your struct, and call that. This is missing the point. The point of a destructor is that it runs automatically. .deinit() is the same as the three cleanup_*()s in my example and thus has the same problems. >but in the case of zig, your function would be parametrized on the type, so you would issue it a struct to be shared by the tests that has the common initialization upfront The third example in my post shows why this is inadequate.

dnautics 5y ago
Then im not really sure what your point is, because I've written zig code that reuses code in a similar way to what you are talking about, with three different forms of parallelism calling into some common runner code each of which has different needs for resource cleanup times (single threaded, cooperative, and independent parallelism). It wasn't a problem. Have you tried doing what you propose in zig? Ultimately, the only difference between a .deinit() and a destructor is that one is explicit and the other is not. There are cases where you can easily make a mistake for both an explicit destructor and an implicit destructor.