That part of the spec refers to variables (which the spec calls VSlots), not objects (which the spec calls HStores).
Objects have different lifetimes, and the spec actually allows the destructors to be run anytime between the object being dead and the program ending. So it looks like there won't be any RAII here.
No RAII would be a big change in the behavior of PHP; you should add that information to your critique. I have code that relies on RAII for error recovery and rollback. Any PHP implementation that doesn't do RAII is going to subtly break a lot of code.
It doesn't make sense to force very specific memory lifetimes for variables and then also not do it for objects.
Yeah, I think you're right. The specific language is:
> Later, if a VStore or HStore becomes unreachable through any existing variable, they become eligible for reclamation to release the memory they occupy. The engine may reclaim a VStore or HStore at any time between when it becomes eligible for reclamation and when the script exits. Before reclaiming an HStore that represents an object, the Engine will invoke the object's destructor if one is defined.
The problem being it's not RAII but a side-effect of reference-counting[0] (Python had the same issue, it's been a pain for alternative implementations and a big reason for `with` being added to the language)
[0] it doesn't work when there's a cycle for instance
PHP developers specifically took into consideration RAII when designing the language. This is why the finally clause for exceptions was not originally part of the language -- it was unnecessary for cleanup if you have RAII. Cycles don't really affect RAII in meaningful way.
> PHP developers specifically took into consideration RAII when designing the language.
No part of that phrase matches reality.
> Cycles don't really affect RAII in meaningful way.
Which is irrelevant because once again what PHP has is not RAII it's reference counting, same as CPython and Objective-C. And because it's refcounting it does have an impact: objects involved in or linked from a cycle are not immediately cleaned up once the cycle goes out of scope because all objects still have a refcount of at least 1.
It's true. When exception handling was added to PHP, RAII was absolutely factored into the design. This is why it didn't get a finally clause to start with -- it's unnecessary.
> Which is irrelevant because once again what PHP has is not RAII it's reference counting
If you have reference counting or stack allocated objects than you can do RAII. You seem to be confused as what these terms mean -- they are not contradictory, they are complimentary. Ref counting allows RAII.
Objects have different lifetimes, and the spec actually allows the destructors to be run anytime between the object being dead and the program ending. So it looks like there won't be any RAII here.