finalizersP6

about "finalization":

becouse discusion keeps to be DESTROYed by GC:

TL;DR: (current) GCs are wrong subsystem to implement
"finalization" feature

teoretically:

"finalization" is considered part of object "destroing"
which is simetric to object "creation", which includes object
"initialization"

so "finalization" aka "cleanup" is symetric to "initialization"
and eg. connecting to db is thinked as part of object
initialization...

<dreaming>
...so programmers constantly requests general, automagic,
per object resource management feature (not tied to 'try'
block like 'finally' in C++)

{
  $dbh = setup_db(params);
  <code> ... <code>;
  #commented becouse not needed anymore
  #$dbh.cleanup(); # yay! \o/
}

LEAVE works for simple (lexical) cases (like in *inside*
setup_db routine).

but whould be realy nice if such cleanup was *guaranteed*
to fire up instantly and exactly after last $dbh object
ocurrence (last as in runtime...)
</dreaming>

IMHO things are messed in industry becouse gc was
available and already was tracing live objets so was
simply reused for (delayed!no guaranee!object
resurection!) finalization...

ref counting works too :)  cycles strike again...

but (maybe) if SSA analysis (or other smart thing) happens early
it could detect that object is no more reachable so it could insert
cleanup routine. or maybe macro could automagically insert routine
only in last object ocurrence ?


that would be good for single actions like file/db handlers closing.
but how about geekosaur++ double file syncing (two actions),
or more complex actions, eg. which must happen in specific order?
tree of actions so new layer maybe or just proper design...


so GC object lifetime management is low level, specialized and
automatic but resources are broader category and have usage
tied to domain objects which can be more complicated eg. can
require immediate action or special ordering


Notes:

- RAII is for exceptional resource handling
- finalizers are supoused to do cleanup before object destruction but
  resource management with finalizers is considered anti-pattern (becouse
  they are executed as part of (postponed) destruction by gc)...
- dispose pattern is tied to lexical scope like LEAVE and can be missed during
  refactoring, etc
- http://en.wikipedia.org/wiki/Finalizer#Problems  quite a list, really needs
  some invention... or decoupling from GC or separate threatment