On Wednesday, 28 June 2017 at 09:16:22 UTC, Guillaume Piolat
wrote:
On Wednesday, 28 June 2017 at 02:13:10 UTC, Jonathan M Davis
wrote:
There are definitely cases where finalizers make sense. Case
in point: if you have a socket class, it makes perfect sense
for it to have a finalizer. Yes, it's better to close it
manually, but it will work just fine for the GC to close it
when finalizing the class object so long as you don't use so
many sockets that you run out before the GC collects them. So,
having a finalizer is a good backup to ensure that the socket
resource doesn't leak.
- Jonathan M Davis
So far everyone is ignoring my example when A needs B to be
destroyed. This happens as soon as you use DerelictUtil for
example.
And I'm gonna rant a little bit more.
Deterministic destruction is a _solved_ problem in C++, and a
number of users to convert are now coming from C++.
We should:
1. be honest and tell things as they are: it's more complicated
than in C++, but also liberating when you know to juggle between
GC and deterministic
2. Avoid making bogus suggestions which don't always work, such
as close() methods, releasing resource with GC, . They only work
for _some_ resources.
3. Suggest a systematic, always working, workaround (or
language change such as "GC doesn't call ~this). C++ users have
no difficulty having an object graph with detailed ownership
schemes, that's what they do day in day out.
It's important to have a _simple_ story about resource release,
else we will talk about "GC" every day, and hearing about "GC" is
bad for marketing.
