Re: [PHP-DEV] Fwd: CS
I remember we agreed that OO code will have studlyCaps. I don't want to have this long thread again (I was actually initially opposed but got convinced/gave in). You don't want a long thread? Then don't mention the topic. As I don't have the time right now nor the setup, can someone please revert and put the studlyCaps guidelines for OO extensions back into the Code Guidelines? Nay. Derick was right about removing that section. - Sascha -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fwd: CS
On Wed, 21 Jan 2004, Andi Gutmans wrote: At 08:21 AM 1/21/2004 +0100, Sascha Schumann wrote: I remember we agreed that OO code will have studlyCaps. I don't want to have this long thread again (I was actually initially opposed but got convinced/gave in). You don't want a long thread? Then don't mention the topic. I don't want *another* long thread because we came to agreement on the previous one. If you don't like the result that's your problem. Huh? There certainly was no agreement. The thread basically closed with you declaring that you changed your opinion. But you are not the judge (nor am I). No agreement in sight. - Sascha -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fwd: CS
Hello Sascha, Wednesday, January 21, 2004, 8:21:30 AM, you wrote: I remember we agreed that OO code will have studlyCaps. I don't want to have this long thread again (I was actually initially opposed but got convinced/gave in). You don't want a long thread? Then don't mention the topic. As I don't have the time right now nor the setup, can someone please revert and put the studlyCaps guidelines for OO extensions back into the Code Guidelines? Nay. Derick was right about removing that section. Yesturday we had an irc discussion about this issue too. And we came to the conclusion once again that all oo guys wnat it and only a few non oo guys don't want it. Besides such things it was meant to make php objects consistent intheir naming scheme and consisten with the rest of the oo world too. The main point against it was that we couldn't keep the original writing in error messages, reflection and such. Now we can and all oo extensions follow studlyCaps i put it back. Thanks Andi for noticing it once again. -- Best regards, Marcusmailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Tidy, CS, OO, Vote
Alright.. I've got a patch sitting here on my laptop that converts all of the OO syntax in the tidy extension into studlyCaps. I.e. $tidy = tidy_parse_file(); or $tidy = new tidy(); $tidy-parse_file(); Will become.. $tidy = tidy_parse_file() or $tidy = new tidy(); $tidy-parseFile(); Although my *personal* preference here is to maintain the current use of underscores (since it is consistent with the procedural API).. as far as PHP 5 goes itself I don't really have an opinion. I'm willing to apply this patch, but before I do can I please get a +1 -1 vote on this? *please* no discussion, I just want to be done changing the API so the documentation team can actually do something productive. John -- -=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=- John Coggeshall http://www.coggeshall.org/ The PHP Developer's Handbookhttp://www.php-handbook.com/ -=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tidy, CS, OO, Vote
PHP 5 goes itself I don't really have an opinion. I'm willing to apply this patch, but before I do can I please get a +1 -1 vote on this? -1 There really is no reason to convert existing code. - Sascha -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tidy, CS, OO, Vote
On Wed, Jan 21, 2004 at 03:00:39AM -0500, John Coggeshall wrote: Although my *personal* preference here is to maintain the current use of underscores (since it is consistent with the procedural API).. as far as PHP 5 goes itself I don't really have an opinion. I'm willing to apply this patch, but before I do can I please get a +1 -1 vote on this? +0 (I'm comfortable either way with a preference for consistency.) -- Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fwd: CS
At 08:38 AM 1/21/2004 +0100, Sascha Schumann wrote: On Wed, 21 Jan 2004, Andi Gutmans wrote: At 08:21 AM 1/21/2004 +0100, Sascha Schumann wrote: I remember we agreed that OO code will have studlyCaps. I don't want to have this long thread again (I was actually initially opposed but got convinced/gave in). You don't want a long thread? Then don't mention the topic. I don't want *another* long thread because we came to agreement on the previous one. If you don't like the result that's your problem. Huh? There certainly was no agreement. The thread basically closed with you declaring that you changed your opinion. But you are not the judge (nor am I). No agreement in sight. Sascha, The majority were for it and that was one of the reasons I changed my opinion. You are just being difficult in trying to fight the majority yet again. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tidy, CS, OO, Vote
Go ahead with it. Please commit it. I hope Sascha will relax with another one of his holy wars. Andi At 03:00 AM 1/21/2004 -0500, John Coggeshall wrote: Alright.. I've got a patch sitting here on my laptop that converts all of the OO syntax in the tidy extension into studlyCaps. I.e. $tidy = tidy_parse_file(); or $tidy = new tidy(); $tidy-parse_file(); Will become.. $tidy = tidy_parse_file() or $tidy = new tidy(); $tidy-parseFile(); Although my *personal* preference here is to maintain the current use of underscores (since it is consistent with the procedural API).. as far as PHP 5 goes itself I don't really have an opinion. I'm willing to apply this patch, but before I do can I please get a +1 -1 vote on this? *please* no discussion, I just want to be done changing the API so the documentation team can actually do something productive. John -- -=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=- John Coggeshall http://www.coggeshall.org/ The PHP Developer's Handbookhttp://www.php-handbook.com/ -=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=- -- 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
[PHP-DEV] [PATCH] Removal of deprecated 'gpc_order' php.ini option
Attached is a patch to FINALLY get rid of the deprecated php.ini option 'gpc_order'. We've had note in the manual also about it not even existing in PHP4 for ages.. Does anyone have any really good reason why it can NOT be removed before PHP 5 goes gold? There is no BC issue, variables_order will default to what it already is defaulting to in php.ini-*, so the behaviour stays the same even without any php.ini. --Jani ? errors.txt ? php.ini Index: php.ini-dist === RCS file: /repository/php-src/php.ini-dist,v retrieving revision 1.203 diff -u -r1.203 php.ini-dist --- php.ini-dist18 Dec 2003 02:06:00 - 1.203 +++ php.ini-dist21 Jan 2004 10:08:50 - @@ -382,9 +382,6 @@ ; Maximum size of POST data that PHP will accept. post_max_size = 8M -; This directive is deprecated. Use variables_order instead. -gpc_order = GPC - ; Magic quotes ; Index: php.ini-recommended === RCS file: /repository/php-src/php.ini-recommended,v retrieving revision 1.148 diff -u -r1.148 php.ini-recommended --- php.ini-recommended 18 Dec 2003 02:06:00 - 1.148 +++ php.ini-recommended 21 Jan 2004 10:08:51 - @@ -401,9 +401,6 @@ ; Maximum size of POST data that PHP will accept. post_max_size = 8M -; This directive is deprecated. Use variables_order instead. -gpc_order = GPC - ; Magic quotes ; Index: main/main.c === RCS file: /repository/php-src/main/main.c,v retrieving revision 1.585 diff -u -r1.585 main.c --- main/main.c 8 Jan 2004 08:17:53 - 1.585 +++ main/main.c 21 Jan 2004 10:08:54 - @@ -297,7 +297,6 @@ STD_PHP_INI_ENTRY(default_mimetype, SAPI_DEFAULT_MIMETYPE, PHP_INI_ALL,OnUpdateString, default_mimetype, sapi_globals_struct,sapi_globals) STD_PHP_INI_ENTRY(error_log, NULL, PHP_INI_ALL,OnUpdateString, error_log, php_core_globals, core_globals) STD_PHP_INI_ENTRY(extension_dir, PHP_EXTENSION_DIR, PHP_INI_SYSTEM, OnUpdateStringUnempty, extension_dir, php_core_globals, core_globals) - STD_PHP_INI_ENTRY(gpc_order, GPC, PHP_INI_ALL,OnUpdateStringUnempty, gpc_order, php_core_globals, core_globals) STD_PHP_INI_ENTRY(include_path, PHP_INCLUDE_PATH, PHP_INI_ALL,OnUpdateStringUnempty, include_path, php_core_globals, core_globals) PHP_INI_ENTRY(max_execution_time, 30, PHP_INI_ALL,OnUpdateTimeout) STD_PHP_INI_ENTRY(open_basedir, NULL, PHP_INI_SYSTEM, OnUpdateString, open_basedir, php_core_globals, core_globals) @@ -309,7 +308,7 @@ STD_PHP_INI_ENTRY(upload_tmp_dir, NULL, PHP_INI_SYSTEM, OnUpdateStringUnempty, upload_tmp_dir, php_core_globals, core_globals) STD_PHP_INI_ENTRY(user_dir, NULL, PHP_INI_SYSTEM, OnUpdateString, user_dir, php_core_globals, core_globals) - STD_PHP_INI_ENTRY(variables_order,NULL, PHP_INI_ALL, OnUpdateStringUnempty, variables_order,php_core_globals, core_globals) + STD_PHP_INI_ENTRY(variables_order,EGPCS,PHP_INI_ALL, OnUpdateStringUnempty, variables_order,php_core_globals, core_globals) STD_PHP_INI_ENTRY(error_append_string,NULL, PHP_INI_ALL, OnUpdateString, error_append_string,php_core_globals, core_globals) STD_PHP_INI_ENTRY(error_prepend_string, NULL, PHP_INI_ALL, OnUpdateString, error_prepend_string, php_core_globals, core_globals) Index: main/php_globals.h === RCS file: /repository/php-src/main/php_globals.h,v retrieving revision 1.95 diff -u -r1.95 php_globals.h --- main/php_globals.h 8 Jan 2004 17:33:04 - 1.95 +++ main/php_globals.h 21 Jan 2004 10:08:54 - @@ -103,7 +103,6 @@ arg_separators arg_separator; - char *gpc_order; char *variables_order; HashTable rfc1867_protected_variables; Index: main/php_variables.c === RCS file:
Re: [PHP-DEV] Tidy, CS, OO, Vote
On Wed, 2004-01-21 at 05:04, Andi Gutmans wrote: Go ahead with it. Please commit it. I hope Sascha will relax with another one of his holy wars. Done. -- -=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=- John Coggeshall http://www.coggeshall.org/ The PHP Developer's Handbookhttp://www.php-handbook.com/ -=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Casting of objects to array exports private/protected data
In general, I think casting an object to an array sucks.
I would be all for an E_STRICT message that this is deprecated as we have
real objects now and IMO, and that the behavior might change/go away
sometime in the future.
Andi
At 05:07 PM 1/17/2004 +0100, Andrey Hristov wrote:
Pierre-Alain Joye wrote:
On Sat, 17 Jan 2004 16:44:29 +0100
Andrey Hristov [EMAIL PROTECTED] wrote:
IMO, when casting to array with (array) only the public-ly visible
members should returned.
Dunno, E_STRICT (as you can access them without notice/warning without
this flag)?
In the same manner:
?php
error_reporting(E_STRICT);
class some {
public $pub = 1;
protected $prot = 2;
private $priv = 3;
}
class any extends some {
public $pub1 = 1;
function dump() {
var_dump($this);
}
}
var_dump((array)new any());
$a = new any;
$a-dump();
?
a var_dump should dump protected props from the parent class as they are
visible. Note the funny thing is that var_dump() alone do not display
the public|protected props, whatever is the context call. IMHO, that
sounds not very consistent, but only imho...
Yes, it does not. Use print_r() for dumping. print_r() uses internal zend
function to dump the variable content while var_dump() is defined in
ext/standard/var.c and knows nothing
about protected and private functions (or at least it was that 2 months ago).
print_r() has the expected behavior of dumping data, but casting to array
and getting protected/private data is nasty.
Andrey
--
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] Exception from the feature freeze mode
I think it's OK. It's very simple and thus shouldn't create any problems. Andi At 06:16 PM 1/17/2004 +0100, Andrey Hristov wrote: Hi internals and Andi, what do you think about a small exception from the feature freeze for satisfying feature request http://bugs.php.net/bug.php?id=24258 . The patch is here : http://www.hristov.com/andrey/projects/php_stuff/array_keys_strict.diff.txt The change is not big and imo does not introduce any bug :) Andrey -- 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
[PHP-DEV] New function proposal urlappendvar()
Hello list,
I find often myself wanting to append a variable to an unknown url. The
problem is that you don't know if you should append the var with ? or
with . Do you think it would be useful to have a builtin function that
would do this automatically?
example code as I do it actually:
?php
$foo = mt_rand();
$separator = (ereg('?', $_SERVER['HTTP_REFERER'])) ? '' : '?';
$url = $_SERVER['HTTP_REFERER'].$separator.'foo='.$foo;
?
example code with the new version:
?php
$foo = mt_rand();
$url = urlappendvar($_SERVER['HTTP_REFERER'], 'foo', $foo);
?
I use it quite frequently so I thought it could be useful to have such
functionality builtin.
What do you think?
--
Juan Alonso Hernández
Desarrollo, Seguridad y Sistemas
www.art3mis.com | (34) 91 530 16 33
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP include/url fopen
I just saw this message now. I'll look into it. Thanks, Andi At 12:56 PM 1/17/2004 -0800, choinet wrote: --- choinet [EMAIL PROTECTED] wrote: I was helping a user at my ISP support forums. Using include on an http:// url generates Warning: main(): stream does not support seeking in /home/account/public_html/test.php on line 2. This occurs for both external/same-server http:// urls. Each of the servers I used run PHP 4.3.4, and I had no warning on Windows as well as on another Linux setup (server generating the warning runs Linux). Searching the warning on google shows the first result http://www.onaje.com/php/article.php4/43, which mentions the problem on 4.3.4. I see two bug reports dealing with this, #24053 and #26550, not sure if it has been resolved yet in the snaps from reading the report (I can't test it out since the ISPs run the server that generates the warning). I don't know what would be causing the warning to output (since it may be assumed that an http:// stream does not support seeking). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I just verified what the other users at #24053 claimed (that Zend Optimizer causes the warnings in http includes) on my Fedora testbed. Also, looking at the phpinfo's of each Red Hat Linux server, only those with PHP 4.3.4 on ZO (2.1.0) generated the warnings, not those with the older 4.3.3/ZO. And, of course, no warning as expected on standalone 4.3.4 or 4.3.4/ZO on Windows. I'm thinking it may be Linux-exclusive(?) Anyway, I know that Zeev and Andi are devs here and maybe we could get some feedback on this? __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus -- 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] Casting of objects to array exports private/protected data
Why not simply make the cast not work?
Can you think of any BC problem with that? :)
--Jani
On Wed, 21 Jan 2004, Andi Gutmans wrote:
In general, I think casting an object to an array sucks.
I would be all for an E_STRICT message that this is deprecated as we have
real objects now and IMO, and that the behavior might change/go away
sometime in the future.
Andi
At 05:07 PM 1/17/2004 +0100, Andrey Hristov wrote:
Pierre-Alain Joye wrote:
On Sat, 17 Jan 2004 16:44:29 +0100
Andrey Hristov [EMAIL PROTECTED] wrote:
IMO, when casting to array with (array) only the public-ly visible
members should returned.
Dunno, E_STRICT (as you can access them without notice/warning without
this flag)?
In the same manner:
?php
error_reporting(E_STRICT);
class some {
public $pub = 1;
protected $prot = 2;
private $priv = 3;
}
class any extends some {
public $pub1 = 1;
function dump() {
var_dump($this);
}
}
var_dump((array)new any());
$a = new any;
$a-dump();
?
a var_dump should dump protected props from the parent class as they are
visible. Note the funny thing is that var_dump() alone do not display
the public|protected props, whatever is the context call. IMHO, that
sounds not very consistent, but only imho...
Yes, it does not. Use print_r() for dumping. print_r() uses internal zend
function to dump the variable content while var_dump() is defined in
ext/standard/var.c and knows nothing
about protected and private functions (or at least it was that 2 months ago).
print_r() has the expected behavior of dumping data, but casting to array
and getting protected/private data is nasty.
Andrey
--
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] Casting of objects to array exports private/protected data
Yeah, because it used to work.
Andi
At 01:19 PM 1/21/2004 +0200, Jani Taskinen wrote:
Why not simply make the cast not work?
Can you think of any BC problem with that? :)
--Jani
On Wed, 21 Jan 2004, Andi Gutmans wrote:
In general, I think casting an object to an array sucks.
I would be all for an E_STRICT message that this is deprecated as we have
real objects now and IMO, and that the behavior might change/go away
sometime in the future.
Andi
At 05:07 PM 1/17/2004 +0100, Andrey Hristov wrote:
Pierre-Alain Joye wrote:
On Sat, 17 Jan 2004 16:44:29 +0100
Andrey Hristov [EMAIL PROTECTED] wrote:
IMO, when casting to array with (array) only the public-ly visible
members should returned.
Dunno, E_STRICT (as you can access them without notice/warning without
this flag)?
In the same manner:
?php
error_reporting(E_STRICT);
class some {
public $pub = 1;
protected $prot = 2;
private $priv = 3;
}
class any extends some {
public $pub1 = 1;
function dump() {
var_dump($this);
}
}
var_dump((array)new any());
$a = new any;
$a-dump();
?
a var_dump should dump protected props from the parent class as they are
visible. Note the funny thing is that var_dump() alone do not display
the public|protected props, whatever is the context call. IMHO, that
sounds not very consistent, but only imho...
Yes, it does not. Use print_r() for dumping. print_r() uses internal zend
function to dump the variable content while var_dump() is defined in
ext/standard/var.c and knows nothing
about protected and private functions (or at least it was that 2 months
ago).
print_r() has the expected behavior of dumping data, but casting to array
and getting protected/private data is nasty.
Andrey
--
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] New function proposal urlappendvar()
Generally we don't add functions to replace simple one-line PHP
expressions.
$url .= strstr($url,'?')??foo=$foo:foo=$foo;
-Rasmus
On Wed, 21 Jan 2004, Juan Alonso wrote:
Hello list,
I find often myself wanting to append a variable to an unknown url. The
problem is that you don't know if you should append the var with ? or
with . Do you think it would be useful to have a builtin function that
would do this automatically?
example code as I do it actually:
?php
$foo = mt_rand();
$separator = (ereg('?', $_SERVER['HTTP_REFERER'])) ? '' : '?';
$url = $_SERVER['HTTP_REFERER'].$separator.'foo='.$foo;
?
example code with the new version:
?php
$foo = mt_rand();
$url = urlappendvar($_SERVER['HTTP_REFERER'], 'foo', $foo);
?
I use it quite frequently so I thought it could be useful to have such
functionality builtin.
What do you think?
--
Juan Alonso Hernández
Desarrollo, Seguridad y Sistemas
www.art3mis.com | (34) 91 530 16 33
--
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] solution for DL's using atexit()
I don't know if we should get into this. Do we *really* care if we crash on exit? We are talking about MSHUTDOWN not RSHUTDOWN here. It's not an ideal situation but I wouldn't want screw things in PHP just for these dumb shared libraries :) Andi At 02:36 PM 1/20/2004 +0100, Ard Biesheuvel wrote: Hello group, I'm looking for a way to fix http://bugs.php.net/26968. This bug is caused by the underlying client .so using atexit() to register a cleanup function. As the library is unloaded before process shutdown, the atexit() stack no longer contains a valid reference when it is called, resulting in a segfault. IMO there are three ways to fix this: - Use some linker magic to redirect the call to atexit() to a wrapper function that effectively nulls it, and call the cleanup function ourselves in the MSHUTDOWN function. I'm not sure if this is possible, so any help is appreciated. - Disallow unloading of the PHP module. I'm not sure if this is a good idea, but it seems to be the most portable solution, and the most unintrusive, because it will only affect those who actually use the module. - Link the main binary to the client .so instead of just the PHP module. This will make sure that the cleanup function is present when exit() is called, but it kind of defeats the purpose of using shared modules in the first place. Of course, the best solution would be to nuke the atexit() call from the client .so, but since this problem has been around for so long, in both Interbase and Firebird, I'm afraid it's something we will have to deal with ourselves. -- Ard -- 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] solution for DL's using atexit()
I don't know if we should get into this. Do we *really* care if we crash on exit? Are you serious ?? Of course we care about segfaults, don't we, even if it's 'only' on exit ?? We are talking about MSHUTDOWN not RSHUTDOWN here. It's not an Depends if you use dl() or load from php.ini. If loaded by dl(), it will segfault on every request. ideal situation but I wouldn't want screw things in PHP just for these dumb shared libraries :) Actually, I've already committed a patch which will omit the dlclose() call. This means the module will not be available if you do not dl() it on every request, but it won't be dlclose()'d after you've loaded it once. Note that this will only affect users who have the interbase.so and actually use it. -- Ard -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] To check in NetWare changes.
Hi, I am working on porting PHP 5.0 onto NetWare. I would like to start checking in the changes into the PHP 5.0 source code branch. What is the project name that I need to check in? Thanks, Ananth. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] solution for DL's using atexit()
At 12:42 PM 1/21/2004 +0100, Ard Biesheuvel wrote: I don't know if we should get into this. Do we *really* care if we crash on exit? Are you serious ?? Of course we care about segfaults, don't we, even if it's 'only' on exit ?? What I'm saying is that if it were to require some ugly hacks in PHP to get around this problem, which besides crashing on apachectl stop and having a line in your error_log it might not be the best idea to fix it. We are talking about MSHUTDOWN not RSHUTDOWN here. It's not an Depends if you use dl() or load from php.ini. If loaded by dl(), it will segfault on every request. dl() is evil and should be deprecated. Actually that reminds me to add an E_STRICT about it. Shared libraries should only be loaded via php.ini. ideal situation but I wouldn't want screw things in PHP just for these dumb shared libraries :) Actually, I've already committed a patch which will omit the dlclose() call. This means the module will not be available if you do not dl() it on every request, but it won't be dlclose()'d after you've loaded it once. Note that this will only affect users who have the interbase.so and actually use it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] To check in NetWare changes.
At 04:48 AM 1/21/2004 -0700, Ananth Kesari wrote: Hi, I am working on porting PHP 5.0 onto NetWare. I would like to start checking in the changes into the PHP 5.0 source code branch. What is the project name that I need to check in? Ananth, We are in a code-freeze now. You are welcome to commit bug fixes to the CVS but if this requires serious changes then you're going to have to save them for 5.0.1. You can checkout the php5 module and commit there (on HEAD). Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New function proposal urlappendvar()
At 07:53 PM 1/21/2004 +0800, James Devenish wrote: In message [EMAIL PROTECTED] on Wed, Jan 21, 2004 at 03:31:08AM -0800, Rasmus Lerdorf wrote: $url = urlappendvar($_SERVER['HTTP_REFERER'], 'foo', $foo); Generally we don't add functions to replace simple one-line PHP expressions. $url .= strstr($url,'?')??foo=$foo:foo=$foo; Without wanting to make any comment about the merits of the proposed function, I would have thought there would be merit in having a set of generalised URL-manipulation functions (if someone wanted to write them, that is). For example, the urlappendvar function would clearly handle the syntax of URLs transparently, yet the one-liner requires an author to do The Right Thing in a piecemeal fashion. I agree that it might be a good idea. There are only two problems: a) The name of the function. b) The timing (we are in a feature freeze right now). I suggest you bring it up again once we release 5.0.0. I'm sure that it has the potential to spawn an intellectual discussion on what the function should look like and other features which are often needed (i.e. it might become something more interesting). Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Removal of deprecated 'gpc_order' php.ini option
There is some BC issue, because if you configured gpc_order for something specific and you rely on it, this setting will be silently ignored... I *think* it's probably not that popular to change it, and that it's becoming less and less of an issue with the autoglobals. But on the other hand, why do you want to remove it if it doesn't cause any problems (or does it?)? Zeev At 12:14 21/01/2004, Jani Taskinen wrote: Attached is a patch to FINALLY get rid of the deprecated php.ini option 'gpc_order'. We've had note in the manual also about it not even existing in PHP4 for ages.. Does anyone have any really good reason why it can NOT be removed before PHP 5 goes gold? There is no BC issue, variables_order will default to what it already is defaulting to in php.ini-*, so the behaviour stays the same even without any php.ini. --Jani -- 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] New function proposal urlappendvar()
James Devenish wrote: $url .= strstr($url,'?')??foo=$foo:foo=$foo; Without wanting to make any comment about the merits of the proposed function, I would have thought there would be merit in having a set of generalised URL-manipulation functions (if someone wanted to write them, that is). Shouldn't that go into separate module (available from PEAR) or something? Sticking as many things into the core as possible seems to be the reason a lot of people don't like PHP ;) -- Petras Kudaras aka moxliukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] solution for DL's using atexit()
dl() is evil and should be deprecated. Actually that reminds me to add an E_STRICT about it. Shared libraries should only be loaded via php.ini. How about setting 'enable_dl' to 'Off' in php.ini-recommended ? -- Ard -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] solution for DL's using atexit()
On Wed, 21 Jan 2004 14:06:55 +0100 Ard Biesheuvel [EMAIL PROTECTED] wrote: dl() is evil and should be deprecated. Actually that reminds me to add an E_STRICT about it. Shared libraries should only be loaded via php.ini. How about setting 'enable_dl' to 'Off' in php.ini-recommended ? Are you kidding? :) AFAIK and see the crash occurs only in debug mode. Why would you like to disable by default (or recommand to) disable dl? Dynamic load on extensions is a very usefull feature. I cannot imagine to live without it. pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New function proposal urlappendvar()
In message [EMAIL PROTECTED] on Wed, Jan 21, 2004 at 02:43:57PM +0100, Petras Kudaras wrote: Shouldn't that go into separate module (available from PEAR) or something? Sticking as many things into the core as possible seems to be the reason a lot of people don't like PHP ;) I don't know what your preferred style is, nor what the best API would be, so I don't attempt to make direct stylistic recommendations. However, personally, I don't see why most users would appreciate such features being hidden in PEAR (no offence intended!) when other frequently-used string-handling functions are part of the compiled-in modules (e.g. parse_url, urlencode, addslashes, htmlentities, mysql_escape_string, etc.). You may conceive of URLs as objects that should have a class structure in PEAR, but I suspect that manipulating query strings and anchors is a vital procedural task in a vast number of PHP scripts. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] solution for DL's using atexit()
I agree; we can't deprecate dl(). There are some very common legitimate cases where it is really useful, such as loading extensions that are not often needed into a CGI (you don't want those in php.ini as they can slow down your process startup). --Wez. dl() is evil and should be deprecated. Actually that reminds me to add an E_STRICT about it. Shared libraries should only be loaded via php.ini. How about setting 'enable_dl' to 'Off' in php.ini-recommended ? Are you kidding? :) AFAIK and see the crash occurs only in debug mode. Why would you like to disable by default (or recommand to) disable dl? Dynamic load on extensions is a very usefull feature. I cannot imagine to live without it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: ahmed
I am so sorry about the last time , I didn't understand good but now its realy very clear to me, okay this what we will do : 1- any translations works ( English =}] Arabic ) 2-make an arabic interface 3-protect your rights in Jordan , Saudi Arabia and UAE __ I will need the cvs account just to do the translations works and in case you liked the idea to have an Arabic interface , you may wonder why ?? becoz some of the Arabian People use the open source projekts and scripts,coz they don't want to know anything more about it __ I have an Idea about someone of the main PHP developers comes to Jordan and we will host him _ I will be already have everything set to talk about php in one of the Greatest Universities in Jordan ( AL - Yarmook ) and the ARABIAN WORLD _ you should know that Microsoft has a taining center in that universty _ I love Jordan and I am sure you will Jordan is the best Arabian Countrey in the Information service and the internet _ all I want is to let THE ARAB WORLD SEE PHP like I do _ I hope to see news about php in Arabic -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] solution for DL's using atexit()
Wez Furlong wrote: I agree; we can't deprecate dl(). There are some very common legitimate cases where it is really useful, such as loading extensions that are not often needed into a CGI (you don't want those in php.ini as they can slow down your process startup). I agree, but perhaps we should make it clearer that using dl() in general is not the recommended way of using modules, because of the performance penalty and security implications. Changing the recommended setting of enable_dl is a first step. AFAIK and see the crash occurs only in debug mode. The crash that started this thread had to do with modules being unloaded, both in debug and release builds. This has already been fixed. -- Ard -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New function proposal urlappendvar()
I agree with Rasmus, I don´t believe that it is necessary to add a new
function that can be solved with a simple line in PHP, another thing would
be to be able to make the function your same one and to add it to your PHP.
You can add into ext/standard/string.c your function.
Iván Rodriguez Espada
_
ALAPLAYA.COM
http://www.alaplaya.com
[EMAIL PROTECTED]
- Original Message -
From: Rasmus Lerdorf [EMAIL PROTECTED]
To: Juan Alonso [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Wednesday, January 21, 2004 12:31 PM
Subject: Re: [PHP-DEV] New function proposal urlappendvar()
Generally we don't add functions to replace simple one-line PHP
expressions.
$url .= strstr($url,'?')??foo=$foo:foo=$foo;
-Rasmus
On Wed, 21 Jan 2004, Juan Alonso wrote:
Hello list,
I find often myself wanting to append a variable to an unknown url. The
problem is that you don't know if you should append the var with ? or
with . Do you think it would be useful to have a builtin function that
would do this automatically?
example code as I do it actually:
?php
$foo = mt_rand();
$separator = (ereg('?', $_SERVER['HTTP_REFERER'])) ? '' : '?';
$url = $_SERVER['HTTP_REFERER'].$separator.'foo='.$foo;
?
example code with the new version:
?php
$foo = mt_rand();
$url = urlappendvar($_SERVER['HTTP_REFERER'], 'foo', $foo);
?
I use it quite frequently so I thought it could be useful to have such
functionality builtin.
What do you think?
--
Juan Alonso Hernández
Desarrollo, Seguridad y Sistemas
www.art3mis.com | (34) 91 530 16 33
--
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] solution for DL's using atexit()
On Wed, 21 Jan 2004 14:52:57 +0100 Ard Biesheuvel [EMAIL PROTECTED] wrote: Changing the recommended setting of enable_dl is a first step. I disagree. Set enable_dl Off in the recommanded php.ini will make it disabled in many situations. This is not something good. But this discussions sounds like 'Do we have to educate endusers?'. Wez sample usage is the perfect example. And the one where I mostly use dl. The crash that started this thread had to do with modules being unloaded, both in debug and release builds. This has already been fixed. Ilia posted about this bug weeks ago (as an explanation about my own post about that), while trying to find why pecl/date crash on exit, using debug mode, shared module(does not crash if statically linked). btw still crash here, using fresh head (linux RH9 stock install). pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Casting of objects to array exports private/protected data
On Wed, 21 Jan 2004, Andi Gutmans wrote: In general, I think casting an object to an array sucks. I would be all for an E_STRICT message that this is deprecated as we have real objects now and IMO, and that... ...the behavior might change/go away sometime in the future. Are you saying you want to introduce a __toArray() method? :) Ducks. -adam PS: In case this wasn't clear: This is a joke. -- [EMAIL PROTECTED] author of o'reilly's php cookbook avoid the holiday rush, buy your copy today! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] solution for DL's using atexit()
Changing the recommended setting of enable_dl is a first step. I disagree. Set enable_dl Off in the recommanded php.ini will make it disabled in many situations. This is not something good. But this discussions sounds like 'Do we have to educate endusers?'. Wez sample usage is the perfect example. And the one where I mostly use dl. Why recommend anything at all if you don't want to 'educate end users' ? The crash that started this thread had to do with modules being unloaded, both in debug and release builds. This has already been fixed. btw still crash here, using fresh head (linux RH9 stock install). The crash I am talking about (#26968) was indeed fixed by implementing one of the proposed changes. (I suspect you're talking about something else here) -- Ard -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fwd: CS
On Wed, 21 Jan 2004, Andi Gutmans wrote: *see above*. Derick did this without consultation and even if you agree or don't agree with it, he shouldn't have done it in the first place. I added it without consultation too, that was wrong, so I corrected it :) Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] To check in NetWare changes.
On Wed, 21 Jan 2004, Ananth Kesari wrote: I am working on porting PHP 5.0 onto NetWare. I would like to start checking in the changes into the PHP 5.0 source code branch. What is the project name that I need to check in? Please show us some patches first. I remember from last time that a lot of kinda ugly things were added, and we'd like to prevent that and find a better solution this time. regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] buildconf
Do fresh checkout of 'php5' module. You'll get all correct
files then, no need to checkout ZendEngine2 separately..
--Jani
On Wed, 21 Jan 2004, Patrick Welche wrote:
I just cvs update -A a php4 src tree to get php5 (had to checkout ZendEngine2),
and assume that the next thing to do is run buildconf. One thing: after
the dance of mv ZendEngine2 Zend, future cvs updates are going to miss
ZendEngine2 and this will no longer be updated - would a symlink be a better
plan?
The last line of buildconf 1.62 says:
${MAKE:-make} -s -f build/build.mk AMFLAGS=$automake_flags ZENDDIR=$ZENDDIR
but
% find . -name build.mk -print
./ZendEngine1/build/build.mk
./Zend/build.mk
./TSRM/build/build.mk
so, no build/build.mk... (the one in Zend aka ZendEngine2 is old, the other
two are the same - presumably its one of those we want)
Cheers,
Patrick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: robinhood
Translating documentation to Russian language. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] interfaces extending multiple interfaces
Andi Gutmans wrote:
Zeev is planning on fixing this.
Cool.
Interfaces should be allowed to extend other interfaces but not
to implement them.
interface Bar extends Foo {}
works already (at least last time I checked). What I need (and meant) is
interface Barbara extends Bar, Foo {}
Just to make sure :-),
Sebastian
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] schedule for 4.3.5
Hi Folks: I'm close to competing major bug fixes and enhancements to PEAR DB. It would be nice if it can get into the upcoming 4.3.5 release. Is this still possible? If so, what's the deadline, please? Thanks, --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fwd: CS
Remind me to remove your Karma :) At 07:08 PM 1/21/2004 +0100, Derick Rethans wrote: On Wed, 21 Jan 2004, Andi Gutmans wrote: *see above*. Derick did this without consultation and even if you agree or don't agree with it, he shouldn't have done it in the first place. I added it without consultation too, that was wrong, so I corrected it :) Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Removal of deprecated 'gpc_order' php.ini option
On Wed, 21 Jan 2004, Zeev Suraski wrote: There is some BC issue, because if you configured gpc_order for something specific and you rely on it, this setting will be silently ignored... Well, my patch makes variables_order to default to EGPCS so it wouldn't mean the variables wouldn't be available.. And I would guess it's VERY rare that someone a) even uses gpc_order (given the note about it being deprecated since PHP 4.0.0 was released, afaik) b) if they 'use' it, it's just because they either don't read, or they totally ignore our recommendations gpc_order only lets you control GPC, they'd still have E S set anyway, right? So the only BC prob would be that someone had changed the order, ie. uses 'gpc_order = CPG' or something similar. In which case they also don't use register_globals where this would have any meaning in the first place. I *think* it's probably not that popular to change it, and that it's becoming less and less of an issue with the autoglobals. But on the other Right. And that's the point for removing the confusion for people who DO use register_globals. hand, why do you want to remove it if it doesn't cause any problems (or does it?)? One reason to remove it is that there's no point having two ini options doing the same thing, where one overrides the other. (the confusion :) Other reason to remove it is to cleanup the code. (okay, it's minimal, but still :) Another reason to remove it is that we've said in manual for ages that the option doesn't even exist in PHP 4. :) And last reason, we're gonna release a major version. And that doesn't happen very often so this would be very good time to remove this kind of stuff. (I think it's very, VERY small possibility that this would cause any problems for anyone) --Jani p.s. I actually removed this to clear up php_variables.c when I was trying to figure out what causes bug http://bugs.php.net/bug.php?id=25724 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] solution for DL's using atexit()
Why is PHP the only scripting language that has an issue with loading binary extensions at run time? :( Shane Ard Biesheuvel wrote: Wez Furlong wrote: I agree; we can't deprecate dl(). There are some very common legitimate cases where it is really useful, such as loading extensions that are not often needed into a CGI (you don't want those in php.ini as they can slow down your process startup). I agree, but perhaps we should make it clearer that using dl() in general is not the recommended way of using modules, because of the performance penalty and security implications. Changing the recommended setting of enable_dl is a first step. AFAIK and see the crash occurs only in debug mode. The crash that started this thread had to do with modules being unloaded, both in debug and release builds. This has already been fixed. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
