Maybe PHP Isn't So Hot, Afterall

I've always thought, and this project only assures me of it, that to really learn to do something, you have to put the skill into use - really use it. If you want to learn Japanese, you can read all the grammar and look at all the anime you can, but you can't be fluent until you get yourself to Japan and really talk (and perhaps write) the language with the natives for, say, a year. The same applies to skills like driving a car, playing instruments, cooking, warfare (yes, conducting warfare truly is a skill), ...everything. Not that that dry theory has hurt anyone, but it's only complementary.

Well, thanks to LightFrame and stubbornness, I've got a really big portion of serious usage of PHP, object oriented programming and SQL. I've already commented on the SQL standard and its reality and also shared my opinions of OOP design. Well, after further hacking and stretching the original use intentions of certain features, I've crossed another gripe. I'm not sure if it's again one of those "but it's not OOP", of just a PHP deficiency, but I can't self-destruct objects. No, unset($this) doesn't do anything, doing $this = null gives an error and $this->__destruct() doesn't work that way. I always thought $this was a pointer to the current object, but apparently it isn't... perhaps it's one of those language constructs (i.e. "hard coded features").

"But why on earth would you want to do that?" I hear you asking. The reason is that I want an explicit destructor that doesn't operate through __destruct(). "Ergh... but wh-" ...because I don't want it to happen every time the object is destroyed, only when it's explicitly triggered, and also unset($foo) isn't suitably aesthetic for the context. "So put a property that disables the object, once the object should be unusable, then." I know I write ugly code, but that would hardly help the matter.