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
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),
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
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
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 :)
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
-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);
28 matches
Mail list logo
