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]

Reply via email to