...my points 2 & 3…
Here we have a departure of thoughts. I don’t want to propose that I know or can foresee the logic every developer will use to for “their” vision of the perfect application. I do know that when viewed in the context of a state machine, I believe you logic is somewhat flawed. For example, in the connected state, the dev can perform a set of operations in one know profile. In the disconnected state, the application can take on a completely different profile with different context altogether. The DB object is relevant in both states, the connection the database is not. However in your analysis, you’ve lumped them together.
Succinctly, if you destroy the DB object you also destry access to its methods and members that need to persist from on state to another (such as the DB Helper Class et. al.).
Perhaps it would be better to capture the state and test for that rather than simply testing for !$this->db->conn_id. Something similar to !$this->db->active is just as simple, yet much more effective from a logic point of view. It could capture the state of the machine rather than the state of the connection.
I agree that this would be a cleaner approach, but to be honest I see that a bit more pragmatically, as we’re talking about a simple web-SERVER-framework, which usually runs once per request as the goal is to create a response on a simple client-server protocol. It doesn’t even try to influence the client directly, it talks to the client in a pre-defined and agreed on language and status codes (lets leave javascript aside).
I don’t really see in that context where the DB object is relevant to both states, especially because you invoke a method which only purpose is to insert data into the database.
Your example doesn’t extend the Database class, your example just uses the unmodified Database object, and the only advertised and documented properties of this database object is to retrieve, insert and modify data in a database.
If you would extend the database object, and would implement other functionality (lets say a general data-holding class, which might or might not actually save data to any form of database, or your reporting class, where some log-data might get logged to the database or to lets say the client) then i would wholeheartedly agree with you 😊 then you’d have an object with several states.
I know i am nitpicking here, and your argument still holds water, i just didn’t see your argument in your code :p
And as told before, which might be to the untrained eye seem like a flame-war, all’s good and fine, for some people this is just daily stuff :D
Frank