Why not flushing on destruct?

[ChristianRiesen]

I was just looking at the library and it struck me odd why there is no destructor defined that would flush. Is that on purpose and if so whats the rationale behind it? If there is nothing against it I'd gladly add it in.

[lyrixx]

Because it's better to be explicit. Then, right now, you have full control on when the flush is done. But you can still create an object that do that for you ;)

[ChristianRiesen]

The question is more then, what is the use case to actually collect data and then NOT flush? Sure, you can do it explicitly, but it should be so there is virtually no overhead on flushing if there is nothing to flush.

[lyrixx]

For example, if you use symfony2, all destructors will be called after the $response->send(). As you can see we call fastcgi_finish_request and so it becomes hard to debug your metric if something goes wrong.

Of course, we can still register a shutdown function that just call flush(). Like that, the end user could still be explicit.

So right now, I'm not :-1: nor :+1: for this issue.

Can we stay with this issue open for few days, in order to get more feedback ?

[ChristianRiesen]

If something goes horribly wrong at that stage, using metrics inside symfony is probably not the place that will reliably inform you about it either.

[lyrixx]

@nicolas-grekas: Do you have a thought on this one ?

[nicolas-grekas]

To me, magic is always a bad idea, and destructors are magic in PHP, so I'd say it's better not having auto-flush here (although that does not prevent anyone adding a wrapper that adds exactly this magic).

[lyrixx]

I agree with @nicolas-grekas