So I do not see the need of a explicit class deconstructor, because the
language should already react correctly on this issues as I can see so
far
The language cannot know the order of dependencies and how to destruct
them.
A dependcy between destructors of instances, which the language have to
know by itself that sounds horrific indeed.
If one instance has destruction dependcies to other instances, you
should have used any kind of linking pattern between this instances so
the __destruct of the first instance destructed can handle the
destruction dependcies. At the moment I cannot think about any use case,
where this should be done another way. Maybe you have a concret example
for me, so I can think about this?
a) Implicit order of dependencies:
Logger should be the last destructed
DatabaseLogger before FileLogger before error_log-Logger...
b) How to destruct:
Write "Bye!" before closing socket.
On destruction/unload of a class the language should be able to unset
static properties in random order for this reason, without any need of a
class destructor?!
Reverse creation order.