emulate __destruct() in PHP4

[hennagaijin]

Is there an elegant way to emulate a destructor in PHP4?

register_shutdown_function() won't work, since it doesn't get called if the object is unset() or reassigned, etc.

Any thoughts? Thanks very much.

[bonefry]

if you have resources to close it is bad practice to use PHP5's __destroy function anyway, because with resources that needs to be closed explicitely (files or database connections) you need to have total control over the closing process.

Why ? Because you don't know how the garbage collector really behaves, do you ? I mean, are you really sure it executes __destroy() all the time in PHP5 ? I am not.

Another reason is that any exceptions or errors that get thrown inside a __destroy() are automatically ignored, so if there is an error in there, you will never know about it.

[hennagaijin]

Thanks - it's not for closing a resource, though. It's basically a situation where something needs to be logged, but it should only happen at the last possible second. In theory I could go through and explicitly call some kind of $object->log() method, but that would require a ton of code changes.

[bonefry]

You can use the php.ini settings: auto_prepend_file and auto_append_file, which tell the PHP engine to loads the scripts automatically at the beginning and at the end of request respectivelly.

But you will have to have permissions to modify php.ini or to have .htaccess files.

[hennagaijin]

Thanks, bonefry, but that still doesn't solve the following situation:

$object = &new Object;
$object->doSomething();

$object = &new DifferentObject;
$object->doSomethingElse();

In that case, I need the first object to carry out some logic automatically when it ceases to exist due to the pointer being reassigned. Same goes for if it had been unset().

[bonefry]

Thanks, bonefry, but that still doesn't solve the following situation:

$object = &new Object;
$object->doSomething();

$object = &new DifferentObject;
$object->doSomethingElse();

In that case, I need the first object to carry out some logic automatically when it ceases to exist due to the pointer being reassigned. Same goes for if it had been unset().

You can have a collection of registered objects that need to be logged when the request exits. Something like:

$object = &new Object;
$object->doSomething();
$logger->register($object);

$object = &new DifferentObject;
$object->doSomethingElse();
$logger->register($object);

And if Object and DifferentObject have both implemented a function called logOnDestroy() for example you do something like:

class Logger {
   var $objects = array();
   function register($object) {
      $objects[] = $object;
   }
   function logThemAll()
   {
      foreach ($objects AS $object)
         $object->logOnDestroy();
   }
}

and you can have in the auto_append_file something like:

   $logger->logThemAll();

[Dr Livingston]

As an alternative, you could use the Intercepting Filter pattern, which I would favour as there would be no need to 1) Change your INI file, and 2 ) Have the pre and post inclusion files, ie

// front controller
// ...
public function execute() {
$logger = new Logger( 'log-file.xml' );
$filter = new FilterOne( $logger, new FilterTwo( $logger, new FilterThree( $logger, $this ) ) );
$filter -> process();
}
// ...
public function process() {
// process front controller action at this point
}
// ... 

And you have the following, for example

class FilterOne implements IFilter {
private $logger;
private $filter;

public function __construct( ILogger $logger, IFilter $filter ) {
$this -> filter = $filter;
$this -> logger = $logger;
}

public function process() {
// do pre processing here
$this -> filter -> process();
// do post processing here, ie
$this -> logger -> doLog( ... );
}
}

class FilterTwo implements IFilter {
private $filter;
private $logger;

public function __construct( ILogger $logger, IFilter $filter ) {
$this -> filter = $filter;
$this -> logger = $logger;
}

public function process() {
// pre processing
$this -> filter -> process();
// post processing
$this -> logger -> doLog( ... );
}
}

class FilterThree implements ...

interface ILogger { ... }
interface IFilter {
public function __construct( ILogger $logger, IFilter $filter );
public function process();
} 

Does that give you some ideas I hope?

[bonefry]

I don't think he has a front controller

[hennagaijin]

Yes, that's useful. It's a bit heavyhanded for my needs at the moment, but I'll play around with it. Really I should just upgrade to PHP5, since __destruct() does exactly what I need!

[hennagaijin]

I don't think he has a front controller

Actually, if a front controller is what I think it is (can't say that I'm sure of that), then I have some simplified version of it (namely a Controller class that delegates business logic to various subclasses based on context and user input).

The current version of my Controller, though, doesn't have any feature to handle clean up in this way. Shouldn't be too hard to implement, but I'm not sure I really need it right now.

[mx2k]

if you have resources to close it is bad practice to use PHP5's __destroy function anyway, because with resources that needs to be closed explicitely (files or database connections) you need to have total control over the closing process.

Why ? Because you don't know how the garbage collector really behaves, do you ? I mean, are you really sure it executes __destroy() all the time in PHP5 ? I am not.

Another reason is that any exceptions or errors that get thrown inside a __destroy() are automatically ignored, so if there is an error in there, you will never know about it.

cough,its__destruct()coughcoughasindestructor

[Nigel McNie]

Have a look at the way PEAR emulates destructors. I haven't looked in detail but PEAR has them...

[Eric.Coleman]

it uses register_shutdown_function afaik...

If you really wanna use it, instantiate your class with an obsecure name then register it :/

- Eric

[Dr Livingston]

It's a bit heavyhanded for my needs at the moment, but I'll play around with it.

I see... Well, how about removing the filters and have the Logger for the filtering instead? For example,

// front controller again
// ...
public function execute() {
// your objects you want to log perhaps yes?
$filter = new Logger( $object_1, new Logger( $object_2, new Logger( $this ) ) );
$filter -> process();
// ...
}

public function process() {
// do your thing here
}
// ... 

And you have this, which is a lot clearner I presume?

class Logger implements ILogger {
private $obj;
private $filter;

public function __construct( $object, ILogger $logger ) {
$this -> obj = $object;
$this -> filter = $logger;
}

public function process() {
// ... execute your object at this point, and
$this -> filter -> process();
// then do the logging here
}

private function doLog( $object ) {
// ...
// or you could abstract to allow a number of 
// different loggers...
}

}

interface ILogger {
public function __construct( $object, ILogger $logger );
public function process();
} 

I was thinking of this earlier today, and took note you said there was a slight overhead on the original idea, so this makes things more manageable, but still giving the benifits of the Intercepting Filters I think

[bonefry]

dude, you think to much in patterns