Re: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0.
Brian Moon [EMAIL PROTECTED] wrote: I am -1 on yet another new function. Because, if you create a new include_local or whatever, people are gonna want include_local_once and so on and so forth. What do you say about include local($str), include_once local($str) ? Just one new function, no more :-) (of course the function name should be different, but I can't figure out a good name right now :-) I think that this include 'bug' should be fixed long before, now it is too late for changes. IMHO it would break many scripts. -- Best regards, Piotr Pawlow mailto:[EMAIL PROTECTED], homepage: http://pp.siedziba.pl -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0.
At 03:19 AM 7/12/2001 +0200, Piotr Pawlow wrote: Brian Moon [EMAIL PROTECTED] wrote: I am -1 on yet another new function. Because, if you create a new include_local or whatever, people are gonna want include_local_once and so on and so forth. What do you say about include local($str), include_once local($str) ? Just one new function, no more :-) (of course the function name should be different, but I can't figure out a good name right now :-) I think that this include 'bug' should be fixed long before, now it is too late for changes. IMHO it would break many scripts. Have you checked the latest CVS? I think I have fixed the problem. In any case, having a function which gives you the path as a result of the path of the executing script might not be such a bad idea. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0.
On Tue, 10 Jul 2001, Andi Gutmans wrote: Does others also think it should wait for 4.1 or later? If so I'll leave it for now (I'll have more free time :). It'd be really nice to have it as soon as possible. ;-) -Andrei * Change is the only constant. * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0.
If we choose to do it in Andi's way (no real drawbacks, considering it's downwards compatible for most practical purposes), we can do it within 4.0. At 16:15 10/7/2001, Andrei Zmievski wrote: On Tue, 10 Jul 2001, Andi Gutmans wrote: Does others also think it should wait for 4.1 or later? If so I'll leave it for now (I'll have more free time :). It'd be really nice to have it as soon as possible. ;-) -Andrei * Change is the only constant. * -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0.
If we choose to do it in Andi's way (no real drawbacks, considering it's downwards compatible for most practical purposes), we can do it within 4.0. This would be even better. To echo what Andrei said, the sooner the better :) I've personally been wishing for this for the longest time! Aral :) __ ([EMAIL PROTECTED]) New Media Producer, Kismia, Inc. ([EMAIL PROTECTED]) Adj. Prof., American University ¯¯ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0.
On Sun, 08 Jul 2001, Andi Gutmans wrote: Hey, I think one thing that bothers PHP developers is when they do: include ../foo.inc; and in foo.inc they do: include bar.inc; That bar.inc is not searched for in foo.inc's current directory automatically. As we pretty much always have the expanded filename of the current executing script I thought it would be nice to add that if bar.inc is not found in the include_path to take the full path of foo.inc (i.e. /path/to/foo_inc/foo.inc) and try opening /path/to/foo_inc/bar.inc. What do you guys think? I'll buy you a beer if this gets done. ;-) -Andrei Give a man a fish; you have fed him for today. Teach a man to fish; and you can sell him fishing equipment. -Author unknown -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0.
Yeah, this has been requested several times. I think that changing the cwd to the directory of an included file makes good sense. It is, indeed, downwards incompatible and may break existing applications. We have 4 options: 1. Do nothing 2. Make include() and friends change directory to the directory of the file they include. This makes the most sense, but may break existing apps. 3. #2, only make it optional 4. Add the directory of the included file to the include_path when the included file is being executed. It can get a bit nasty with nested includes, even though I think it should work. It's also a bit tricky to implement, as the engine doesn't know about include_path (at least right now). I'm leaning towards #3, even though I don't like the yet-another-runtime-option. It may be justified if we say we're phasing out the old functionality in PHP 5.0. Zeev At 18:14 8/7/2001, Andi Gutmans wrote: Hey, I think one thing that bothers PHP developers is when they do: include ../foo.inc; and in foo.inc they do: include bar.inc; That bar.inc is not searched for in foo.inc's current directory automatically. As we pretty much always have the expanded filename of the current executing script I thought it would be nice to add that if bar.inc is not found in the include_path to take the full path of foo.inc (i.e. /path/to/foo_inc/foo.inc) and try opening /path/to/foo_inc/bar.inc. What do you guys think? Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0.
On Mon, 09 Jul 2001, Zeev Suraski wrote: Yeah, this has been requested several times. I think that changing the cwd to the directory of an included file makes good sense. It is, indeed, downwards incompatible and may break existing applications. We have 4 options: 1. Do nothing 2. Make include() and friends change directory to the directory of the file they include. This makes the most sense, but may break existing apps. 3. #2, only make it optional 4. Add the directory of the included file to the include_path when the included file is being executed. It can get a bit nasty with nested includes, even though I think it should work. It's also a bit tricky to implement, as the engine doesn't know about include_path (at least right now). I'm leaning towards #3, even though I don't like the yet-another-runtime-option. It may be justified if we say we're phasing out the old functionality in PHP 5.0. How about #3 for 4.1 and #2 for 5.0? -Andrei * If it's never finished, you can't prove it doesn't work. * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0.
At 10:02 AM 7/9/2001 -0500, Andrei Zmievski wrote: On Sun, 08 Jul 2001, Andi Gutmans wrote: Hey, I think one thing that bothers PHP developers is when they do: include ../foo.inc; and in foo.inc they do: include bar.inc; That bar.inc is not searched for in foo.inc's current directory automatically. As we pretty much always have the expanded filename of the current executing script I thought it would be nice to add that if bar.inc is not found in the include_path to take the full path of foo.inc (i.e. /path/to/foo_inc/foo.inc) and try opening /path/to/foo_inc/bar.inc. What do you guys think? I'll buy you a beer if this gets done. ;-) Now I've got more incentive :) Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0.
How about #3 for 4.1 and #2 for 5.0? This would be wonderful! Aral :) __ ([EMAIL PROTECTED]) New Media Producer, Kismia, Inc. ([EMAIL PROTECTED]) Adj. Prof., American University ¯¯ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0.
At 18:35 9/7/2001, Andrei Zmievski wrote: I'm leaning towards #3, even though I don't like the yet-another-runtime-option. It may be justified if we say we're phasing out the old functionality in PHP 5.0. How about #3 for 4.1 and #2 for 5.0? Yep, that's what I meant. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0.
I actually had in mind something like option #4 but not exactly what Zeev wrote. I thought that what we could do is if cwd and include_path fail then try and open at the same directory level as the currently executing script. I think it can be done but haven't completely checked it from a technical point of view. Andi At 07:50 PM 7/9/2001 +0300, Zeev Suraski wrote: At 18:35 9/7/2001, Andrei Zmievski wrote: I'm leaning towards #3, even though I don't like the yet-another-runtime-option. It may be justified if we say we're phasing out the old functionality in PHP 5.0. How about #3 for 4.1 and #2 for 5.0? Yep, that's what I meant. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0.
Just want to pipe up and say I'm worried about a potential performance hit here. I'm building an enterprise web app that includes over 30 files on every request. Will changing the directory for the include file, and changing it back after create a significant performance hit? (I would think so). Just to point out -- things might get a little more confusing here... because if people get to pretend that the file they are including is being executed in the directory where it is stored, they may have problems adjusting to the idea of making links and images (in HTML) relative to the script that called their file, and they might have to end up re-implementing existing workarounds anyway. Just a thought. -Brian Tanner -Original Message- From: Zeev Suraski [mailto:[EMAIL PROTECTED]] Sent: July 9, 2001 5:48 AM To: Andi Gutmans Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0. Yeah, this has been requested several times. I think that changing the cwd to the directory of an included file makes good sense. It is, indeed, downwards incompatible and may break existing applications. We have 4 options: 1. Do nothing 2. Make include() and friends change directory to the directory of the file they include. This makes the most sense, but may break existing apps. 3. #2, only make it optional 4. Add the directory of the included file to the include_path when the included file is being executed. It can get a bit nasty with nested includes, even though I think it should work. It's also a bit tricky to implement, as the engine doesn't know about include_path (at least right now). I'm leaning towards #3, even though I don't like the yet-another-runtime-option. It may be justified if we say we're phasing out the old functionality in PHP 5.0. Zeev At 18:14 8/7/2001, Andi Gutmans wrote: Hey, I think one thing that bothers PHP developers is when they do: include ../foo.inc; and in foo.inc they do: include bar.inc; That bar.inc is not searched for in foo.inc's current directory automatically. As we pretty much always have the expanded filename of the current executing script I thought it would be nice to add that if bar.inc is not found in the include_path to take the full path of foo.inc (i.e. /path/to/foo_inc/foo.inc) and try opening /path/to/foo_inc/bar.inc. What do you guys think? Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0.
At 12:07 PM 7/9/2001 -0700, Brian Tanner wrote: Just want to pipe up and say I'm worried about a potential performance hit here. I'm building an enterprise web app that includes over 30 files on every request. Will changing the directory for the include file, and changing it back after create a significant performance hit? (I would think so). I think that it will effect performance and therefore I wouldn't want to go in the direction of chdir(). Andi Just to point out -- things might get a little more confusing here... because if people get to pretend that the file they are including is being executed in the directory where it is stored, they may have problems adjusting to the idea of making links and images (in HTML) relative to the script that called their file, and they might have to end up re-implementing existing workarounds anyway. Just a thought. -Brian Tanner -Original Message- From: Zeev Suraski [mailto:[EMAIL PROTECTED]] Sent: July 9, 2001 5:48 AM To: Andi Gutmans Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0. Yeah, this has been requested several times. I think that changing the cwd to the directory of an included file makes good sense. It is, indeed, downwards incompatible and may break existing applications. We have 4 options: 1. Do nothing 2. Make include() and friends change directory to the directory of the file they include. This makes the most sense, but may break existing apps. 3. #2, only make it optional 4. Add the directory of the included file to the include_path when the included file is being executed. It can get a bit nasty with nested includes, even though I think it should work. It's also a bit tricky to implement, as the engine doesn't know about include_path (at least right now). I'm leaning towards #3, even though I don't like the yet-another-runtime-option. It may be justified if we say we're phasing out the old functionality in PHP 5.0. Zeev At 18:14 8/7/2001, Andi Gutmans wrote: Hey, I think one thing that bothers PHP developers is when they do: include ../foo.inc; and in foo.inc they do: include bar.inc; That bar.inc is not searched for in foo.inc's current directory automatically. As we pretty much always have the expanded filename of the current executing script I thought it would be nice to add that if bar.inc is not found in the include_path to take the full path of foo.inc (i.e. /path/to/foo_inc/foo.inc) and try opening /path/to/foo_inc/bar.inc. What do you guys think? Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0.
I think it's the 'right' thing to do, even though that too requires some thinking. If we move to always use the virtual cwd system in TSRM (any reason not to?) then there'll be pretty much no performance implications either. Zeev At 20:08 9/7/2001, Andi Gutmans wrote: At 12:07 PM 7/9/2001 -0700, Brian Tanner wrote: Just want to pipe up and say I'm worried about a potential performance hit here. I'm building an enterprise web app that includes over 30 files on every request. Will changing the directory for the include file, and changing it back after create a significant performance hit? (I would think so). I think that it will effect performance and therefore I wouldn't want to go in the direction of chdir(). Andi Just to point out -- things might get a little more confusing here... because if people get to pretend that the file they are including is being executed in the directory where it is stored, they may have problems adjusting to the idea of making links and images (in HTML) relative to the script that called their file, and they might have to end up re-implementing existing workarounds anyway. Just a thought. -Brian Tanner -Original Message- From: Zeev Suraski [mailto:[EMAIL PROTECTED]] Sent: July 9, 2001 5:48 AM To: Andi Gutmans Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0. Yeah, this has been requested several times. I think that changing the cwd to the directory of an included file makes good sense. It is, indeed, downwards incompatible and may break existing applications. We have 4 options: 1. Do nothing 2. Make include() and friends change directory to the directory of the file they include. This makes the most sense, but may break existing apps. 3. #2, only make it optional 4. Add the directory of the included file to the include_path when the included file is being executed. It can get a bit nasty with nested includes, even though I think it should work. It's also a bit tricky to implement, as the engine doesn't know about include_path (at least right now). I'm leaning towards #3, even though I don't like the yet-another-runtime-option. It may be justified if we say we're phasing out the old functionality in PHP 5.0. Zeev At 18:14 8/7/2001, Andi Gutmans wrote: Hey, I think one thing that bothers PHP developers is when they do: include ../foo.inc; and in foo.inc they do: include bar.inc; That bar.inc is not searched for in foo.inc's current directory automatically. As we pretty much always have the expanded filename of the current executing script I thought it would be nice to add that if bar.inc is not found in the include_path to take the full path of foo.inc (i.e. /path/to/foo_inc/foo.inc) and try opening /path/to/foo_inc/bar.inc. What do you guys think? Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0.
I would *love* to see that! Vlad Andi Gutmans wrote: Hey, I think one thing that bothers PHP developers is when they do: include ../foo.inc; and in foo.inc they do: include bar.inc; That bar.inc is not searched for in foo.inc's current directory automatically. As we pretty much always have the expanded filename of the current executing script I thought it would be nice to add that if bar.inc is not found in the include_path to take the full path of foo.inc (i.e. /path/to/foo_inc/foo.inc) and try opening /path/to/foo_inc/bar.inc. What do you guys think? Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0.
Is it better to break things once or twice? Ok, not completely break, but now I have some code working with PHP4, later I will have some code that will work with PHP4.1, and finally I will re-write it to work with the latest-and-best PHP5. It is more like saying Here is my script, you can run it with this version of PHP *only*, if you want to run it with another one, I have another version of the script for you. On a sidenote, could we just create a different include (e.g. include_relative, like there is include_once) that will incorporate the desired functionality, and not touch include() at all? Or am I suggestiong yet another bloat? Or am I missing the point here? Or did we all agree that the current include() operation is so buggy that it warrants a change breaking compatibility and soon? I do not think that going to 5.0 warrants letting the hell break loose and break everything, I would still like to be able to run at least some of my php4 scripts once php5 comes out, and I have lots of very elaborate solutions to work around the current problems with include(). Such a change will not break my code, but I can easily see what code that *will* break, and I think there will be a lot of it. Vlad Zeev Suraski wrote: At 18:35 9/7/2001, Andrei Zmievski wrote: I'm leaning towards #3, even though I don't like the yet-another-runtime-option. It may be justified if we say we're phasing out the old functionality in PHP 5.0. How about #3 for 4.1 and #2 for 5.0? Yep, that's what I meant. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0.
That is not completely true. If there is a file in the included scripts dir that has the same name as one in the including scripts dir, that would cause some unexpected problems. I still like the idea. Brian Moon -- dealnews.com, Inc. Makers of dealnews dealmac http://dealnews.com/ | http://dealmac.com/ - Original Message - From: Andi Gutmans [EMAIL PROTECTED] To: Vlad Krupin [EMAIL PROTECTED]; Zeev Suraski [EMAIL PROTECTED] Cc: Andrei Zmievski [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, July 09, 2001 2:46 PM Subject: Re: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0. At 12:03 PM 7/9/2001 -0700, Vlad Krupin wrote: Is it better to break things once or twice? Ok, not completely break, but now I have some code working with PHP4, later I will have some code that will work with PHP4.1, and finally I will re-write it to work with the latest-and-best PHP5. It is more like saying Here is my script, you can run it with this version of PHP *only*, if you want to run it with another one, I have another version of the script for you. On a sidenote, could we just create a different include (e.g. include_relative, like there is include_once) that will incorporate the desired functionality, and not touch include() at all? Or am I suggestiong yet another bloat? Or am I missing the point here? Or did we all agree that the current include() operation is so buggy that it warrants a change breaking compatibility and soon? I do not think that going to 5.0 warrants letting the hell break loose and break everything, I would still like to be able to run at least some of my php4 scripts once php5 comes out, and I have lots of very elaborate solutions to work around the current problems with include(). Such a change will not break my code, but I can easily see what code that *will* break, and I think there will be a lot of it. What do you think about the solution I suggested? If the file can't be found to then look in the current scripts directory. It solves the problems and doesn't break BC. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0.
At 03:43 PM 7/9/2001 -0500, Brian Moon wrote: That is not completely true. If there is a file in the included scripts dir that has the same name as one in the including scripts dir, that would cause some unexpected problems. Well as I would only resort to looking according to the current file if all other things fail (cwd and include_path) I can't see how it would break BC. I still like the idea. Thanks :) Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0.
It is not so much BC. It is more like unexpected new behavior. As of now, a bad programmer might have this: /www/site.com/include/file.php /www/site.com/include/config.php /www/site.com/index.php /www/site.com/config.php if index.php includes include/file.php which includes config.php, the config in the main dir gets included. Now, in the future, if the main config.php is not there, the one in the include file gets included. Now, granted, this may not be the best case, but it would cause some confusion if someone was not well aware of this change. I am still +1, but think it should be at least a 4.1 thing. Brian Moon -- dealnews.com, Inc. Makers of dealnews dealmac http://dealnews.com/ | http://dealmac.com/ - Original Message - From: Andi Gutmans [EMAIL PROTECTED] To: Brian Moon [EMAIL PROTECTED]; Vlad Krupin [EMAIL PROTECTED]; Zeev Suraski [EMAIL PROTECTED] Cc: Andrei Zmievski [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, July 09, 2001 3:44 PM Subject: Re: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0. At 03:43 PM 7/9/2001 -0500, Brian Moon wrote: That is not completely true. If there is a file in the included scripts dir that has the same name as one in the including scripts dir, that would cause some unexpected problems. Well as I would only resort to looking according to the current file if all other things fail (cwd and include_path) I can't see how it would break BC. I still like the idea. Thanks :) Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0.
Andi, I definitely do like your approachl. I do not like that different versions of PHP will behave differently. That's what I was talking about. And it is a situation similar to what Brian described that prompted me to write to the list and see if we can come up with one solution which will stay, whether in version 4.1, or 5, or 5.5. I know that I have myriads of includes with a pretty extensive directory structure, and some scripts are having the same names. I have run into problems including the wrong file by mistake. I do not want to make that mistake easier to make. That's why I asked if it makes sense to leave include() as it is, and create another function/construct that will behave as described, and asked if that would be too much of a bloat. I can not judge that myself, for I do not know enough. If it is, discard that idea, but could we please implement something that will not change between verision 4.1 and 5 and hopefully later? Sorry, couldn't reply earlier - I was following up on the heated discussions here... Vlad Brian Moon wrote: It is not so much BC. It is more like unexpected new behavior. As of now, a bad programmer might have this: /www/site.com/include/file.php /www/site.com/include/config.php /www/site.com/index.php /www/site.com/config.php if index.php includes include/file.php which includes config.php, the config in the main dir gets included. Now, in the future, if the main config.php is not there, the one in the include file gets included. Now, granted, this may not be the best case, but it would cause some confusion if someone was not well aware of this change. I am still +1, but think it should be at least a 4.1 thing. Brian Moon -- dealnews.com, Inc. Makers of dealnews dealmac http://dealnews.com/ | http://dealmac.com/ - Original Message - From: Andi Gutmans [EMAIL PROTECTED] To: Brian Moon [EMAIL PROTECTED]; Vlad Krupin [EMAIL PROTECTED]; Zeev Suraski [EMAIL PROTECTED] Cc: Andrei Zmievski [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, July 09, 2001 3:44 PM Subject: Re: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0. At 03:43 PM 7/9/2001 -0500, Brian Moon wrote: That is not completely true. If there is a file in the included scripts dir that has the same name as one in the including scripts dir, that would cause some unexpected problems. Well as I would only resort to looking according to the current file if all other things fail (cwd and include_path) I can't see how it would break BC. I still like the idea. Thanks :) Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0.
I am -1 on yet another new function. Because, if you create a new include_local or whatever, people are gonna want include_local_once and so on and so forth. I am alos -1 on making it an option. Do you know what a headache it is to try and write and app like Phorum and mess with a million different server setups. Brian Moon -- dealnews.com, Inc. Makers of dealnews dealmac http://dealnews.com/ | http://dealmac.com/ - Original Message - From: Vlad Krupin [EMAIL PROTECTED] To: Brian Moon [EMAIL PROTECTED] Cc: Zeev Suraski [EMAIL PROTECTED]; Andi Gutmans [EMAIL PROTECTED]; Andrei Zmievski [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, July 09, 2001 4:49 PM Subject: Re: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0. Andi, I definitely do like your approachl. I do not like that different versions of PHP will behave differently. That's what I was talking about. And it is a situation similar to what Brian described that prompted me to write to the list and see if we can come up with one solution which will stay, whether in version 4.1, or 5, or 5.5. I know that I have myriads of includes with a pretty extensive directory structure, and some scripts are having the same names. I have run into problems including the wrong file by mistake. I do not want to make that mistake easier to make. That's why I asked if it makes sense to leave include() as it is, and create another function/construct that will behave as described, and asked if that would be too much of a bloat. I can not judge that myself, for I do not know enough. If it is, discard that idea, but could we please implement something that will not change between verision 4.1 and 5 and hopefully later? Sorry, couldn't reply earlier - I was following up on the heated discussions here... Vlad Brian Moon wrote: It is not so much BC. It is more like unexpected new behavior. As of now, a bad programmer might have this: /www/site.com/include/file.php /www/site.com/include/config.php /www/site.com/index.php /www/site.com/config.php if index.php includes include/file.php which includes config.php, the config in the main dir gets included. Now, in the future, if the main config.php is not there, the one in the include file gets included. Now, granted, this may not be the best case, but it would cause some confusion if someone was not well aware of this change. I am still +1, but think it should be at least a 4.1 thing. Brian Moon -- dealnews.com, Inc. Makers of dealnews dealmac http://dealnews.com/ | http://dealmac.com/ - Original Message - From: Andi Gutmans [EMAIL PROTECTED] To: Brian Moon [EMAIL PROTECTED]; Vlad Krupin [EMAIL PROTECTED]; Zeev Suraski [EMAIL PROTECTED] Cc: Andrei Zmievski [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, July 09, 2001 3:44 PM Subject: Re: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0. At 03:43 PM 7/9/2001 -0500, Brian Moon wrote: That is not completely true. If there is a file in the included scripts dir that has the same name as one in the including scripts dir, that would cause some unexpected problems. Well as I would only resort to looking according to the current file if all other things fail (cwd and include_path) I can't see how it would break BC. I still like the idea. Thanks :) Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0.
At 02:49 PM 7/9/2001 -0700, Vlad Krupin wrote: Andi, I definitely do like your approachl. I do not like that different versions of PHP will behave differently. That's what I was talking about. And it is a situation similar to what Brian described that prompted me to write to the list and see if we can come up with one solution which will stay, whether in version 4.1, or 5, or 5.5. I know that I have myriads of includes with a pretty extensive directory structure, and some scripts are having the same names. I have run into problems including the wrong file by mistake. I do not want to make that mistake easier to make. That's why I asked if it makes sense to leave include() as it is, and create another function/construct that will behave as described, and asked if that would be too much of a bloat. I can not judge that myself, for I do not know enough. If it is, discard that idea, but could we please implement something that will not change between verision 4.1 and 5 and hopefully later? My intention is to do something which won't change. I don't think it's good to add yet another include() construct. I think if my relatively elegant way doesn't work out technically then we'll have to wait for the next major of PHP and decide if we want to break something or not. Andi Sorry, couldn't reply earlier - I was following up on the heated discussions here... Vlad Brian Moon wrote: It is not so much BC. It is more like unexpected new behavior. As of now, a bad programmer might have this: /www/site.com/include/file.php /www/site.com/include/config.php /www/site.com/index.php /www/site.com/config.php if index.php includes include/file.php which includes config.php, the config in the main dir gets included. Now, in the future, if the main config.php is not there, the one in the include file gets included. Now, granted, this may not be the best case, but it would cause some confusion if someone was not well aware of this change. I am still +1, but think it should be at least a 4.1 thing. Brian Moon -- dealnews.com, Inc. Makers of dealnews dealmac http://dealnews.com/ | http://dealmac.com/ - Original Message - From: Andi Gutmans [EMAIL PROTECTED] To: Brian Moon [EMAIL PROTECTED]; Vlad Krupin [EMAIL PROTECTED]; Zeev Suraski [EMAIL PROTECTED] Cc: Andrei Zmievski [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, July 09, 2001 3:44 PM Subject: Re: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0. At 03:43 PM 7/9/2001 -0500, Brian Moon wrote: That is not completely true. If there is a file in the included scripts dir that has the same name as one in the including scripts dir, that would cause some unexpected problems. Well as I would only resort to looking according to the current file if all other things fail (cwd and include_path) I can't see how it would break BC. I still like the idea. Thanks :) Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0.
At 04:04 PM 7/9/2001 -0500, Brian Moon wrote: It is not so much BC. It is more like unexpected new behavior. As of now, a bad programmer might have this: /www/site.com/include/file.php /www/site.com/include/config.php /www/site.com/index.php /www/site.com/config.php if index.php includes include/file.php which includes config.php, the config in the main dir gets included. Now, in the future, if the main config.php is not there, the one in the include file gets included. Now, granted, this may not be the best case, but it would cause some confusion if someone was not well aware of this change. I am still +1, but think it should be at least a 4.1 thing. Does others also think it should wait for 4.1 or later? If so I'll leave it for now (I'll have more free time :). Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0.
On Tue, 10 Jul 2001, Andi Gutmans wrote: At 04:04 PM 7/9/2001 -0500, Brian Moon wrote: It is not so much BC. It is more like unexpected new behavior. As of now, a bad programmer might have this: /www/site.com/include/file.php /www/site.com/include/config.php /www/site.com/index.php /www/site.com/config.php if index.php includes include/file.php which includes config.php, the config in the main dir gets included. Now, in the future, if the main config.php is not there, the one in the include file gets included. Now, granted, this may not be the best case, but it would cause some confusion if someone was not well aware of this change. I am still +1, but think it should be at least a 4.1 thing. Does others also think it should wait for 4.1 or later? If so I'll leave it I don't. But I consider this more as a bug than missing feature.. So it should be fixed ASAP. :) (there have actually been bug reports about this, IIRC) --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0.
At 07:03 AM 7/10/2001 +0200, Jani Taskinen wrote: I am still +1, but think it should be at least a 4.1 thing. Does others also think it should wait for 4.1 or later? If so I'll leave it I don't. But I consider this more as a bug than missing feature.. So it should be fixed ASAP. :) (there have actually been bug reports about this, IIRC) Yeah many people complain about this *bug*. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0.
Does others also think it should wait for 4.1 or later? I for one would love to see it in 4.1 -- IMVHO This would be a very important feature and a great improvement! Aral :) __ ([EMAIL PROTECTED]) New Media Producer, Kismia, Inc. ([EMAIL PROTECTED]) Adj. Prof., American University ¯¯ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0.
-1 ;) I think it could make thing much more difficult and confusing actually. I like to keep all my include files in a central place, and define a constant __IncPath, where __IncPath is something like: $Document_Root.libraries/ That way I always just: include(__IncPath.foo.php); include(__IncPath.bar.php); I guess this might not be the best in all situations, but I find it makes my code more portable. Define one constant, and all is well. Although for newer users, you guys are probably very right. Makes things much easier when learning. So I guess as long as it doesn't add to ambiguity (would there be include_relative() or include($FilePath[,boolean relative])... could be useful. -Brian Tanner -Original Message- From: Andi Gutmans [mailto:[EMAIL PROTECTED]] Sent: July 8, 2001 9:15 AM To: [EMAIL PROTECTED] Subject: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0. Hey, I think one thing that bothers PHP developers is when they do: include ../foo.inc; and in foo.inc they do: include bar.inc; That bar.inc is not searched for in foo.inc's current directory automatically. As we pretty much always have the expanded filename of the current executing script I thought it would be nice to add that if bar.inc is not found in the include_path to take the full path of foo.inc (i.e. /path/to/foo_inc/foo.inc) and try opening /path/to/foo_inc/bar.inc. What do you guys think? Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
