Re: [PHP-DEV] Destructor Order
On Wed, Oct 22, 2008 at 5:03 AM, Ryan Panning [EMAIL PROTECTED] wrote: I've been wondering, is such a thing even possible? Is there a good way to implement an object destruct order? Here are my thoughts: In the class definition, specify what level of destruction the objects should be on. How, I have no idea, I haven't thought of a good syntax. It should be an integer for what level though. Then when the script ends, the engine starts with the highest most level of destruction. It continues down until everything has been destructed. With the last most level being objects with unspecified levels. Note: Each level can have more than one class. Example destruction order: 3 = database records (ActiveRecord or such) 2 = database connection object 1 = framework objects 0 = objects with unspecified level Why would you need such thing? PHP uses reference-counting and destroys objects as soon, as there are no more references to them. Since PHP 5.3, it also detects cyclic-references and periodically destroys object-groups which have references to each other, but do not have references from external context. -- Alexey Zakhlestin http://blog.milkfarmsoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Destructor Order
Alexey Zakhlestin wrote: On Wed, Oct 22, 2008 at 5:03 AM, Ryan Panning [EMAIL PROTECTED] wrote: I've been wondering, is such a thing even possible? Is there a good way to implement an object destruct order? Here are my thoughts: In the class definition, specify what level of destruction the objects should be on. How, I have no idea, I haven't thought of a good syntax. It should be an integer for what level though. Then when the script ends, the engine starts with the highest most level of destruction. It continues down until everything has been destructed. With the last most level being objects with unspecified levels. Note: Each level can have more than one class. Example destruction order: 3 = database records (ActiveRecord or such) 2 = database connection object 1 = framework objects 0 = objects with unspecified level Why would you need such thing? PHP uses reference-counting and destroys objects as soon, as there are no more references to them. Since PHP 5.3, it also detects cyclic-references and periodically destroys object-groups which have references to each other, but do not have references from external context. Additionally, AFAIK in an ideal situation a destructor should only destroy objects which exist during the lifetime of an instance of the class containing the destructor. If objects have a greater lifespan (i.e. shared) then they should be destroyed by other means, like at the end of their lifespan or at the end of your script. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Destructor Order
On Wed, Oct 22, 2008 at 5:03 AM, Ryan Panning [EMAIL PROTECTED] wrote:
I've been wondering, is such a thing even possible? Is there a good way
to
implement an object destruct order? Here are my thoughts:
In the class definition, specify what level of destruction the objects
should be on. How, I have no idea, I haven't thought of a good syntax.
It
should be an integer for what level though.
Then when the script ends, the engine starts with the highest most level
of
destruction. It continues down until everything has been destructed.
With
the last most level being objects with unspecified levels.
Note: Each level can have more than one class.
Example destruction order:
3 = database records (ActiveRecord or such)
2 = database connection object
1 = framework objects
0 = objects with unspecified level
Hi,
This would likely (and possibly rightfully) be frowned upon, but according
to the current codebase, if the destructor creates a new reference outside
to the destroyed object while it runs, the object won't be garbage collected
(a safe call is used that checks for any remaining references after the
destructor is called).
This allows you to implement destruction priorities yourself easily by using
a central DestructManager:
function __destruct()
{
global $destructManager;
$this-addObject($this, $priority);
}
function __real_destruct()
{
}
Those will be collected in the destruction manager and when at shutdown, on
the manager's own destructor you just need to sort the collection by
priority and call the real destructor.
Now, this will work fine, but has this downside that all objects will be
held in the memory until script shutdown, so it's naturally not good for
long running processes.
Regards,
Stan Vassilev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Destructor Order
Hi, Naturally this line: $this-addObject($this, $priority); was meant to be: $destructManager-addObject($this, $priority); ... Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Allow unsetting headers previously set using header()
Hi,
On Mon, 2008-10-20 at 09:12 +0200, Hannes Magnusson wrote:
I suggest extending the behaviour of header() so that when the first
argument does not contain a colon (and does not begin with HTTP/), e.g.
header('Vary'), it unsets the header with the specified name. I decided to
extend the existing header() function rather than adding a new function,
because the existing function already supports multiple actions (add, append
and replace).
That isn't very intuitive. I would think it was a typo when reading
such code and fix the header line...
I'd suggest explicit header_remove(Vary);
Agreed, a specific function with a clear name sounds better.
Christian, can you update the patch? - thanks!
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Allow unsetting headers previously set usingheader()
That isn't very intuitive. I would think it was a typo when reading
such code and fix the header line...
I'd suggest explicit header_remove(Vary);
Agreed, a specific function with a clear name sounds better.
Christian, can you update the patch? - thanks!
johannes
I suggest header_remove('*') or simply header_remove() /no param/ removes
all headers (including the one PHP sets by default), so we can start with a
clear state.
Regards,
Stan Vassilev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] Bug #46367 - fputcsv does not add the correct newline character on Windows
Hi All, My first patch so be gentle :-). Per the documentation for the fputcsv() function, it adds a newline to the end of the csv string it returns. However, it is hardcoded to be '\n' ( default for unix newline ), while Windows uses \r\n. PHP should do this as well. Below is a patch to fix this issue; it uses the constant PHP_EOL to get the correct newline to use on the current platform: Index: php-src/ext/standard/file.c === RCS file: /repository/php-src/ext/standard/file.c,v retrieving revision 1.530 diff -r1.530 file.c 2107c2107 smart_str_appendc(csvline, '\n'); --- smart_str_appendc(csvline, PHP_EOL); John Mertic [EMAIL PROTECTED] http://jmertic.wordpress.com Explaining a joke is like dissecting a frog: you understand it better, but the frog dies in the process. --Mark Twain -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Bug #46367 - fputcsv does not add the correct newline character on Windows
Hi John, Am Mittwoch, den 22.10.2008, 10:03 -0700 schrieb John Mertic: [...] Below is a patch to fix this issue; it uses the constant PHP_EOL to get the correct newline to use on the current platform: Thanks for your patch. A few things to mention, as it is your first patch: please use diff -ru to create unified diffs. Also we try to always add tests for the things we fix or create. Would you mind creating a test for the fix you sent to make sure no regression happens in the next n years? Thanks, Lars -- Jabber: [EMAIL PROTECTED] Weblog: http://usrportage.de signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] [PATCH] Bug #46367 - fputcsv does not add the correct newline character on Windows
Hi Stefan, The context on how this function is being used is the case where you are writing out to a file, so in this case I think we should be using the EOL standards of the underlying platform. If we were just keeping the output as a string, I could see us sticking with the standard newline character. And also, the function previously took a character and still will take a character ( PHP_EOL is #defined to whatever character string should be used for the EOL character, be it \r\n or \n ), unless I'm missing something ( which could be since I haven't done much C in a while ). John Mertic [EMAIL PROTECTED] http://jmertic.wordpress.com Explaining a joke is like dissecting a frog: you understand it better, but the frog dies in the process. --Mark Twain On Wed, Oct 22, 2008 at 10:14 AM, Stefan Walk [EMAIL PROTECTED] wrote: John Mertic wrote: Hi All, My first patch so be gentle :-). Per the documentation for the fputcsv() function, it adds a newline to the end of the csv string it returns. However, it is hardcoded to be '\n' ( default for unix newline ), while Windows uses \r\n. PHP should do this as well. Below is a patch to fix this issue; it uses the constant PHP_EOL to get the correct newline to use on the current platform: Index: php-src/ext/standard/file.c === RCS file: /repository/php-src/ext/standard/file.c,v retrieving revision 1.530 diff -r1.530 file.c 2107c2107 smart_str_appendc(csvline, '\n'); --- smart_str_appendc(csvline, PHP_EOL); This can't work. Either the function takes a character or a pointer to a character, it can't take both. Also, a newline is \n. Everywhere. The End of line-marker is distinct from that. Regards, Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Bug #46367 - fputcsv does not add the correct newline character on Windows
Hi Lars, Thanks for the pointers, updated the patch and added a test. Index: file.c === RCS file: /repository/php-src/ext/standard/file.c,v retrieving revision 1.530 diff -u -r1.530 file.c --- file.c 21 Oct 2008 22:06:48 - 1.530 +++ file.c 22 Oct 2008 18:21:10 - @@ -2104,7 +2104,7 @@ } } - smart_str_appendc(csvline, '\n'); + smart_str_appendc(csvline, PHP_EOL); smart_str_0(csvline); ret = php_stream_write(stream, csvline.c, csvline.len); John Mertic [EMAIL PROTECTED] http://jmertic.wordpress.com Explaining a joke is like dissecting a frog: you understand it better, but the frog dies in the process. --Mark Twain On Wed, Oct 22, 2008 at 10:36 AM, Lars Strojny [EMAIL PROTECTED] wrote: Hi John, Am Mittwoch, den 22.10.2008, 10:03 -0700 schrieb John Mertic: [...] Below is a patch to fix this issue; it uses the constant PHP_EOL to get the correct newline to use on the current platform: Thanks for your patch. A few things to mention, as it is your first patch: please use diff -ru to create unified diffs. Also we try to always add tests for the things we fix or create. Would you mind creating a test for the fix you sent to make sure no regression happens in the next n years? Thanks, Lars -- Jabber: [EMAIL PROTECTED] Weblog: http://usrportage.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Bug #46367 - fputcsv does not add the correct newline character on Windows
You cannot use smart_str_appendc() in this case, since the EOL could be a 2 byte string \r\n. smart_str_appendl(csvline, PHP_EOL, sizeof(PHP_EOL)-1); should be used here. On 22-Oct-08, at 2:35 PM, John Mertic wrote: Hi Lars, Thanks for the pointers, updated the patch and added a test. Index: file.c === RCS file: /repository/php-src/ext/standard/file.c,v retrieving revision 1.530 diff -u -r1.530 file.c --- file.c 21 Oct 2008 22:06:48 - 1.530 +++ file.c 22 Oct 2008 18:21:10 - @@ -2104,7 +2104,7 @@ } } - smart_str_appendc(csvline, '\n'); + smart_str_appendc(csvline, PHP_EOL); smart_str_0(csvline); ret = php_stream_write(stream, csvline.c, csvline.len); John Mertic [EMAIL PROTECTED] http://jmertic.wordpress.com Explaining a joke is like dissecting a frog: you understand it better, but the frog dies in the process. --Mark Twain On Wed, Oct 22, 2008 at 10:36 AM, Lars Strojny [EMAIL PROTECTED] wrote: Hi John, Am Mittwoch, den 22.10.2008, 10:03 -0700 schrieb John Mertic: [...] Below is a patch to fix this issue; it uses the constant PHP_EOL to get the correct newline to use on the current platform: Thanks for your patch. A few things to mention, as it is your first patch: please use diff -ru to create unified diffs. Also we try to always add tests for the things we fix or create. Would you mind creating a test for the fix you sent to make sure no regression happens in the next n years? Thanks, Lars -- Jabber: [EMAIL PROTECTED] Weblog: http://usrportage.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 5.2.7RC1 Testing
The more that gets moved from php into pecl, the more many of us rely on pecl builds to test php. Specificly in regards to 5.3 and 6.0... On Fri, Oct 17, 2008 at 8:52 AM, Pierre Joye [EMAIL PROTECTED] wrote: hi, All references are now updated, in http://qa.php.net http://bugs.php.net and http://snaps.php.net Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Bug #46367 - fputcsv does not add the correct newline character on Windows
On Wed, Oct 22, 2008 at 1:16 PM, Ilia Alshanetsky [EMAIL PROTECTED] wrote: You cannot use smart_str_appendc() in this case, since the EOL could be a 2 byte string \r\n. smart_str_appendl(csvline, PHP_EOL, sizeof(PHP_EOL)-1); should be used here. On 22-Oct-08, at 2:35 PM, John Mertic wrote: Hi Lars, Thanks for the pointers, updated the patch and added a test. Index: file.c === RCS file: /repository/php-src/ext/standard/file.c,v retrieving revision 1.530 diff -u -r1.530 file.c --- file.c 21 Oct 2008 22:06:48 - 1.530 +++ file.c 22 Oct 2008 18:21:10 - @@ -2104,7 +2104,7 @@ } } - smart_str_appendc(csvline, '\n'); + smart_str_appendc(csvline, PHP_EOL); smart_str_0(csvline); ret = php_stream_write(stream, csvline.c, csvline.len); John Mertic [EMAIL PROTECTED] http://jmertic.wordpress.com Explaining a joke is like dissecting a frog: you understand it better, but the frog dies in the process. --Mark Twain On Wed, Oct 22, 2008 at 10:36 AM, Lars Strojny [EMAIL PROTECTED] wrote: Hi John, Am Mittwoch, den 22.10.2008, 10:03 -0700 schrieb John Mertic: [...] Below is a patch to fix this issue; it uses the constant PHP_EOL to get the correct newline to use on the current platform: Thanks for your patch. A few things to mention, as it is your first patch: please use diff -ru to create unified diffs. Also we try to always add tests for the things we fix or create. Would you mind creating a test for the fix you sent to make sure no regression happens in the next n years? Thanks, Lars -- Jabber: [EMAIL PROTECTED] Weblog: http://usrportage.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Ilia Alshanetsky Hi Ilia, I can see your point about scanner's having trouble with different EOL characters, but I know in our use case the problem is that the CSV files created will come out the lines all mashed together, which is a problem for readability of the file. And since most CSV scanners know how to deal with Windows, I would think we are pretty safe ;-) Attached is an updated patch that uses this function instead. -- John Mertic [EMAIL PROTECTED] | http://jmertic.wordpress.com file.c.patch Description: application/force-download -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Destructor Order
On Wednesday 22 October 2008 2:31:38 am Mike van Riel wrote: Example destruction order: 3 = database records (ActiveRecord or such) 2 = database connection object 1 = framework objects 0 = objects with unspecified level Why would you need such thing? PHP uses reference-counting and destroys objects as soon, as there are no more references to them. Since PHP 5.3, it also detects cyclic-references and periodically destroys object-groups which have references to each other, but do not have references from external context. Additionally, AFAIK in an ideal situation a destructor should only destroy objects which exist during the lifetime of an instance of the class containing the destructor. If objects have a greater lifespan (i.e. shared) then they should be destroyed by other means, like at the end of their lifespan or at the end of your script. I believe the end of your script part is the problem. Imagine you have some object (say, ActiveRecord style) that writes itself to the database when it's destroyed if the data has been modified. Now cache that object in a static variable somewhere for performance. You're also using PDO, so your database connection is a global or singleton instance of the PDO class. Then your script reaches the end. Does your object get destroyed and therefore saved to the database before or after the PDO object goes away? I don't actually know. I'm not saying that manual destructor order is the correct way to deal with that issue necessarily, but I think that's the sort of use case it's intended to address. -- Larry Garfield [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Destructor Order
I believe the end of your script part is the problem. Imagine you have some object (say, ActiveRecord style) that writes itself to the database when it's destroyed if the data has been modified. Now cache that object in a static variable somewhere for performance. You're also using PDO, so your database connection is a global or singleton instance of the PDO class. Then your script reaches the end. Does your object get destroyed and therefore saved to the database before or after the PDO object goes away? I don't actually know. I'm not saying that manual destructor order is the correct way to deal with that issue necessarily, but I think that's the sort of use case it's intended to address. If you want to treat a PHP script as a traditional application, you should be prepared to unset() and keep references of everything yourself. Relying on the garbage collector for your business logic to work is just bad design. I'd personally always explicitly do a -saveObject in similar situations as its predictable and quite frankly never found a use for a destructor other than debugging.. Sounds like a subject that doesn't belong on PHP-DEV in any event. Evert -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
