Everything

php

Home » Project » Newsgroups » php.internals » In regards to E_STRICT and PHP5 »

In regards to E_STRICT and PHP5

php.internals

boots

21 years ago

I was hoping that in the future, E_STRICT wasn't expanded and was
perhaps even taken back a step. I understand the reason for it: code
correctness. Yet if PHP5 is (rightly) considered a runtime engine then
its job should be to evaluate and execute code and in the case of
failure, explain why it could not do so. In other words, if a code
segment is valid, then the runtime should just do its job and run that
code. Code correctness is the job for offline tools like lint. Yes, PHP
is a dynamic language so things like E_NOTICE are often required to be
triggered by the runtime. Yet the only place keywords can be generated
dynamically is through an eval -- and I suggest that getting deprecated
warnings at that point is not very enlightening. There is another
difference between an E_NOTICE and a deprecated warning: the first can
lead to (or mask) programming errors, the second can not. Its almost as
if another error flag (not error level) was needed, something like
E_DEPRECATED. The real question is, should the runtime be concerned
about that or should that be something that the toolchain handles? I
would rather the latter.

If there is any merit to E_STRICT as it stands currently I find it to
be negated by the fact that it throws messages for completely
acceptable code that the engine is both willing and capable of
handling. If var is not acceptable, I think it should be removed as a
keyword. If it is acceptable, the engine shouldn't complain about it.
(of course, I think it is acceptable.)

Very best regards and thanks.

Pawel Bernat

21 years ago

On Thu, Jun 16, 2005 at 09:30:20AM -0700, boots wrote:

> If there is any merit to E_STRICT as it stands currently I find it to
> be negated by the fact that it throws messages for completely
> acceptable code that the engine is both willing and capable of
> handling. If var is not acceptable, I think it should be removed as a
> keyword. If it is acceptable, the engine shouldn't complain about it.
> (of course, I think it is acceptable.)

IMHO "var" is accepted for backward compability. If E_STRICT message
really annoys you, set proper error_reporting level and forget about it.


Regards, P.

--
Paweł Bernat; uselessness' lover;
select'<asm'||chr(64)||'asm'||'.'||'flynet'||chr(46)||'pl>'as email;
Slowly and surely the unix crept up on the Nintendo user ...

Zeev Suraski

21 years ago

Why would you enable it then?  You have to very explicitly enable it, as
it's off by default, and doesn't get enabled even if you switch to E_ALL.

I think it can help, and I don't see how it can hurt given the fact it's
not on unless you want it to.

Zeev


At 19:30 16/06/2005, boots wrote:

Robert Cummings

21 years ago

On Thu, 2005-06-16 at 12:51, Zeev Suraski wrote:

> Why would you enable it then?  You have to very explicitly enable it, as
> it's off by default, and doesn't get enabled even if you switch to E_ALL.
>
> I think it can help, and I don't see how it can hurt given the fact it's
> not on unless you want it to.

Because if you don't enable it, someone else will, and then they'll
complain that your code is broken, when in fact it is not.

Cheers,
Rob.

--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting  |
| a powerful, scalable system for accessing system services  |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for       |
| creating re-usable components quickly and easily.          |
`------------------------------------------------------------'

Dan Scott

21 years ago

On 6/16/05, Zeev Suraski <zeev@zend.com> wrote:

> Why would you enable it then?  You have to very explicitly enable it, as
> it's off by default, and doesn't get enabled even if you switch to E_ALL.

Well, that depends on your definition of "default";
php.ini-recommended in HEAD shows:

;   - Show all errors, including coding standards warnings
;
error_reporting  =  E_ALL | E_STRICT

-- so the user who does 'cp php.ini-recommended /etc/php.ini' is, in
fact, getting E_STRICT by default with the recommended configuration.

Perhaps E_ALL should be the default in php.ini-recommended, with E_ALL
| E_STRICT a documented (but commented) option.

Dan

Zeev Suraski

21 years ago

At 20:39 16/06/2005, Dan Scott wrote:

>On 6/16/05, Zeev Suraski <zeev@zend.com> wrote:
> > Why would you enable it then?  You have to very explicitly enable it, as
> > it's off by default, and doesn't get enabled even if you switch to E_ALL.
>
>Well, that depends on your definition of "default";

I meant what PHP comes with built-in / php.ini-dist.

>php.ini-recommended in HEAD shows:
>
>;   - Show all errors, including coding standards warnings
>;
>error_reporting  =  E_ALL | E_STRICT
>
>-- so the user who does 'cp php.ini-recommended /etc/php.ini' is, in
>fact, getting E_STRICT by default with the recommended configuration.
>
>Perhaps E_ALL should be the default in php.ini-recommended, with E_ALL
>| E_STRICT a documented (but commented) option.

Maybe we should be a bit more clear with what we say there.

Zeev

Dan Scott

21 years ago

On 6/16/05, Zeev Suraski <zeev@zend.com> wrote:

> At 20:39 16/06/2005, Dan Scott wrote:
> >On 6/16/05, Zeev Suraski <zeev@zend.com> wrote:
> > > Why would you enable it then?  You have to very explicitly enable it, as
> > > it's off by default, and doesn't get enabled even if you switch to E_ALL.
> >
> >Well, that depends on your definition of "default";
>
> I meant what PHP comes with built-in / php.ini-dist.
>
> >php.ini-recommended in HEAD shows:
> >
> >;   - Show all errors, including coding standards warnings
> >;
> >error_reporting  =  E_ALL | E_STRICT
> >
> >-- so the user who does 'cp php.ini-recommended /etc/php.ini' is, in
> >fact, getting E_STRICT by default with the recommended configuration.
> >
> >Perhaps E_ALL should be the default in php.ini-recommended, with E_ALL
> >| E_STRICT a documented (but commented) option.
>
> Maybe we should be a bit more clear with what we say there.
>
> Zeev
>

To be fair, INSTALL does say:

If you instead choose php.ini-recommended, be certain to read the list
of changes within, as they affect how PHP behaves.

but php.ini-recommended, in the list of changes vs. php.ini-dist, says:

; - error_reporting = E_ALL        [Code Cleanliness, Security(?)]
;     By default, PHP surpresses errors of type E_NOTICE.  These error messages
;     are emitted for non-critical errors, but that could be a symptom
of a bigger
;     problem.  Most notably, this will cause error messages about the use
;     of uninitialized variables to be displayed.

-- so yes, we need to update this section to note the addition of
E_STRICT and the deprecation warnings to the list.

Suggested patch:

--- php.ini-recommended 2005-06-01 23:27:16.000000000 -0400
+++ php.ini-new 2005-06-16 14:09:01.803325720 -0400
@@ -111,11 +111,12 @@
; - variables_order = "GPCS"       [Performance]
;     The environment variables are not hashed into the $_ENV.  To access
;     environment variables, you can use getenv() instead.
-; - error_reporting = E_ALL        [Code Cleanliness, Security(?)]
-;     By default, PHP surpresses errors of type E_NOTICE.  These error messages
+; - error_reporting = E_ALL | E_STRICT       [Code Cleanliness, Security(?)]
+;     By default, PHP suppresses errors of type E_NOTICE.  These error messages
;     are emitted for non-critical errors, but that could be a
symptom of a bigger
;     problem.  Most notably, this will cause error messages about the use
-;     of uninitialized variables to be displayed.
+;     of uninitialized variables to be displayed. Adding E_STRICT will cause
+;     deprecation warnings for functions like dl() to be displayed.
; - allow_call_time_pass_reference = Off     [Code cleanliness]
;     It's not possible to decide to force a variable to be passed by reference
;     when calling a function.  The PHP 4 style to do this is by making the


Dan

Sara Golemon

21 years ago

> If there is any merit to E_STRICT as it stands currently I find it to
> be negated by the fact that it throws messages for completely
> acceptable code that the engine is both willing and capable of
> handling. If var is not acceptable, I think it should be removed as a
> keyword. If it is acceptable, the engine shouldn't complain about it.
> (of course, I think it is acceptable.)
>

Answer: No, it's not acceptable.  But expecting everyone out there using PHP
to update their code (which they probably didn't write themselves anyway) is
even more unacceptable.  Solution: Throw no warnings in the default error
reporting level, but provide a hook for script developers to find the code
that needs changing.

If anything, E_STRICT needs expanding.  For example, zend_function_entry
should have a flag to indicate deprecation.  When a deprecated method is
called: zend_error(E_STRICT, "Call to deprecated function %s()", fname);

-Sara

Zeev Suraski

21 years ago

At 19:57 16/06/2005, Sara Golemon wrote:

> > If there is any merit to E_STRICT as it stands currently I find it to
> > be negated by the fact that it throws messages for completely
> > acceptable code that the engine is both willing and capable of
> > handling. If var is not acceptable, I think it should be removed as a
> > keyword. If it is acceptable, the engine shouldn't complain about it.
> > (of course, I think it is acceptable.)
> >
>Answer: No, it's not acceptable.  But expecting everyone out there using PHP
>to update their code (which they probably didn't write themselves anyway) is
>even more unacceptable.  Solution: Throw no warnings in the default error
>reporting level, but provide a hook for script developers to find the code
>that needs changing.
>
>If anything, E_STRICT needs expanding.  For example, zend_function_entry
>should have a flag to indicate deprecation.  When a deprecated method is
>called: zend_error(E_STRICT, "Call to deprecated function %s()", fname);

I think that's a good idea.

Zeev

Andi Gutmans

21 years ago

You missed the point of E_STRICT. I introduced it as an E_PEDANTIC. That
was the whole idea. To be pedantic about code that works, not to warn about
code that  doesn't work (which is for higher warning levels)

At 09:30 AM 6/16/2005 -0700, boots wrote:

boots

21 years ago

--- Andi Gutmans <andi@zend.com> wrote:

> You missed the point of E_STRICT. I introduced it as an E_PEDANTIC.
> That  was the whole idea. To be pedantic about code that works, not
> to warn about code that  doesn't work (which is for higher warning
> levels)

I don't think I missed that, I just don't appreciate it :) I'm
suggesting that its not the business of a runtime engine to be pedantic
-- it is the author and the development toolchain that needs to be
pedantic. I think it is noble to implement linting and other checking
in the engine, but in my view that is best enabled by a command line
option rather than an ERROR reporting level. The basic thing I am
getting at is that it causes more confusion than is warranted by the
value of the information it provides.

So, while it is agreeable to give tools to developers that help them
produce more "correct" code the value is lost when it adds to developer
cost in a non-meaningful way. Those same developers that the engine is
trying to help is causing them to repeatedly answer customer queries
and explain that an "error" is not an "error" even though the PHP
engine says it is. The fact that it IS pedantic and unneccessary just
makes it that much harder to appreciate.

It comes down to this: if the PHP5 engine can run a piece of PHP4 code,
it would be very nice if it just did that. One expects error levels to
tell of code problems, not code niceness. It is not that I don't
understand where you are coming from and I certainly appreciate the
fact that you are looking out for developers. I am trying to impart the
idea that it is actually working against us in this instance.

All the best.

George Schlossnagle

21 years ago

On Jun 16, 2005, at 2:50 PM, boots wrote:

> --- Andi Gutmans <andi@zend.com> wrote:
>
>> You missed the point of E_STRICT. I introduced it as an E_PEDANTIC.
>> That  was the whole idea. To be pedantic about code that works, not
>> to warn about code that  doesn't work (which is for higher warning
>> levels)
>>
>
> I don't think I missed that, I just don't appreciate it :)

If you don't want pedantic checks, don't run with E_STRICT.

George

boots

21 years ago

--- George Schlossnagle <george@omniti.com> wrote:

> On Jun 16, 2005, at 2:50 PM, boots wrote:
> > --- Andi Gutmans <andi@zend.com> wrote:
> >
> >> You missed the point of E_STRICT. I introduced it as an
> E_PEDANTIC.
> >> That  was the whole idea. To be pedantic about code that works,
> not
> >> to warn about code that  doesn't work (which is for higher warning
> >> levels)
> >>
> >
> > I don't think I missed that, I just don't appreciate it :)
>
> If you don't want pedantic checks, don't run with E_STRICT.

As a developer, I want to run with E_STRICT, or at least, I want to
know what the engine thinks in regards to the correctness of my code.
That is not the problem. The problem is that I can't control what
customer environments and I don't necessarily want to port perfectly
acceptable PHP4 code to avoid warning on their systems. The point is
that E_STRICT is meant for developers but is implemented in the general
runtime where it impacts more than just developers.

Well, you were all kind enough to allow me to have my say so I will
leave it in your capable hands now and accept your decisions.

Thank-you.

Jason Garber

21 years ago

Hello boots,

if(AppDevLevel == 'Production')
{
error_reporting(E_ALL);
}
else
{
error_reporting(E_ALL | E_STRICT);
}

Why don't you implement something like this in your application -
then you CAN control what error level is used at the client site.

--
Best regards,
Jason                            mailto:jason@ionzoft.com

Thursday, June 16, 2005, 3:09:43 PM, you wrote:

b> --- George Schlossnagle <george@omniti.com> wrote:
>> On Jun 16, 2005, at 2:50 PM, boots wrote:
>> > --- Andi Gutmans <andi@zend.com> wrote:
>> >
>> >> You missed the point of E_STRICT. I introduced it as an
>> E_PEDANTIC.
>> >> That  was the whole idea. To be pedantic about code that works,
>> not
>> >> to warn about code that  doesn't work (which is for higher warning
>> >> levels)
>> >>
>> >
>> > I don't think I missed that, I just don't appreciate it :)
>>
>> If you don't want pedantic checks, don't run with E_STRICT.

b> As a developer, I want to run with E_STRICT, or at least, I want to
b> know what the engine thinks in regards to the correctness of my code.
b> That is not the problem. The problem is that I can't control what
b> customer environments and I don't necessarily want to port perfectly
b> acceptable PHP4 code to avoid warning on their systems. The point is
b> that E_STRICT is meant for developers but is implemented in the general
b> runtime where it impacts more than just developers.

b> Well, you were all kind enough to allow me to have my say so I will
b> leave it in your capable hands now and accept your decisions.

b> Thank-you.

Rasmus Lerdorf

21 years ago

Jason Garber wrote:

> Hello boots,
>
>   if(AppDevLevel == 'Production')
>   {
>      error_reporting(E_ALL);
>   }
>   else
>   {
>      error_reporting(E_ALL | E_STRICT);
>   }
>
>   Why don't you implement something like this in your application -
>   then you CAN control what error level is used at the client site.

Because setting E_SCRIPT at runtime is mostly useless as many of the
E_STRICT checks are compile-time.

-Rasmus

Jason Garber

21 years ago

Hello Rasmus,

Thanks.  I guess I did not realize that because all of my
application logic is included after I set error_reporting()

Thanks for pointing this out.

--
Best regards,
Jason                            mailto:jason@ionzoft.com

Thursday, June 16, 2005, 4:32:11 PM, you wrote:

RL> Jason Garber wrote:
>> Hello boots,
>>
>>   if(AppDevLevel == 'Production')
>>   {
>>      error_reporting(E_ALL);
>>   }
>>   else
>>   {
>>      error_reporting(E_ALL | E_STRICT);
>>   }
>>
>>   Why don't you implement something like this in your application -
>>   then you CAN control what error level is used at the client site.

RL> Because setting E_SCRIPT at runtime is mostly useless as many of the
RL> E_STRICT checks are compile-time.

RL> -Rasmus

Stanislav Malyshev

21 years ago

RL>>Because setting E_SCRIPT at runtime is mostly useless as many of the
RL>>E_STRICT checks are compile-time.

auto_prepend?

--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com  http://www.zend.com/ +972-3-6139665 ext.115

Andi Gutmans

21 years ago

I suggest you use E_ALL.

At 11:50 AM 6/16/2005 -0700, boots wrote:

boots

21 years ago

These answers make me feel as if maybe just a little bit you guys are
looking down your nose at me without really considering the basis of
the issue I am trying to raise. I know the tools well enough to use
E_ALL -- thanks. I'm concerned about end users who don't know enough to
help themselves -- but whom I have to support. I'm talking about
problems running PHP4 codebases on a PHP5 engine.

So what can I reasonably do? My options seem to be: a) recode my PHP4
apps; b) explain to my clients the reasons for the "errors" and what to
do about them; c) tell them not to upgrade to PHP5 and avoid the
situation entirely. Those are all bad solutions in my mind and they
stem from the simple fact that error reporting is being used to report
non-error conditions. Just as try/catch shouldn't implement application
logic, it is reasonable to assume that error reporting will be
constrained to bona fide errors. E_STRICT is a wonderful idea -- I just
wish it was implemented separately from the normal error handling,
that's all. An important thing to remember is that a client's
configuration, PHP version and codebase mix is typically out of my
control and I don't like looking bad just because the runtime is taking
it on itself to tell the world about irrelevant differences between
PHP4 and PHP5. Those differences are important to you and me, not
end-users.

Is it a huge issue? Absolutely not! Still, it is exceptionally annoying
and it can be avoided (simple: just send E_STRICT to its own logfile).
As I said before, I am satisfied to have my say and I completely
respect your decisions. I am also grateful for the kind treatment and
responses I received. So I apologize for the interuption and this time
I will bow out -- unless someone else thinks it is necessary to tell me
about E_ALL.

Greetings.

--- Andi Gutmans <andi@zend.com> wrote:

George Schlossnagle

21 years ago

On Jun 16, 2005, at 10:15 PM, boots wrote:

> These answers make me feel as if maybe just a little bit you guys are
> looking down your nose at me without really considering the basis of
> the issue I am trying to raise. I know the tools well enough to use
> E_ALL -- thanks. I'm concerned about end users who don't know
> enough to
> help themselves -- but whom I have to support. I'm talking about
> problems running PHP4 codebases on a PHP5 engine.

E_STRICT isn't part of E_ALL and isn't on by default.  If your
clients have the relatively basic sophistication you describe, how do
you think they'll stumble into E_STRICT?  It's a pedantic error
warning, just like gcc -pedantic.  To paraphrase, I didn't miss your
point, I just don't appreciate it.

George

Daniel Convissor

21 years ago

Hi George:

On Fri, Jun 17, 2005 at 01:53:29AM -0400, George Schlossnagle wrote:

>
> E_STRICT isn't part of E_ALL and isn't on by default.

Just to be clear, E_STRICT is off by default in 5.0 but on by default in
5.1.

--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

Zeev Suraski

21 years ago

At 14:39 17/06/2005, Daniel Convissor wrote:

>Hi George:
>
>On Fri, Jun 17, 2005 at 01:53:29AM -0400, George Schlossnagle wrote:
> >
> > E_STRICT isn't part of E_ALL and isn't on by default.
>
>Just to be clear, E_STRICT is off by default in 5.0 but on by default in
>5.1.

Where do you see that?  As far as I can tell it certainly looks off by
default even in 5.1.

Zeev

Nicholas Telford

21 years ago

Hello everyone,

It seems that E_STRICT is on by default in php.ini-recommended as of 5.1

I think the real issue here is nothing to do with E_STRICT being too
strict, it does what it says, and as Andi has already said, it's there
as a means of best practice checking for pedantic developers.

The problem is that far too many people look at the distribution, see
"php.ini-recommended" and think that they should be using it, this isn't
to say that they shouldn't, but they should at least be aware that
-recommended means that everything is set up to be as tight as possible.

I propose changing php.ini-recommended's error reporting level to simply
E_ALL. Those developers who require E_STRICT know how to turn it on and
will do so.

I agree with Sara that E_STRICT could probably do with expanding, having
it simply checking for depreceated stuff is all well and good, but it's
name implies that it will alert the developer to anything not considered
strictly correct coding practice.

Since this thread spawned off the one about adding public to PHP4.4,
it's probably not worth it, not due to backwards compatability (try
running code written for 4.3.x under 4.0.0...), but mostly because it'd
effectively be creating an intermediary branch between PHP 4 and PHP 5
that would be neither one nor the other. It's probably just best to
allow people to make the move to PHP 5 over a longer period of time.
Besides, as Andrey said, you can just insert the keywords and have them
commented out until the entire app is ported.

Sorry for the rather lengthy post, I've been watching these discussions
with great interest over the last few days and have only now had the
chance to post my thoughts.

Nicholas Telford

Daniel Convissor

21 years ago

Hi Zeev:

On Sat, Jun 18, 2005 at 12:59:31PM +0300, Zeev Suraski wrote:

> Where do you see that?  As far as I can tell it certainly looks off by
> default even in 5.1.

http://cvs.php.net/php-src/php.ini-recommended#rev1.173

That change is still in there as version 1.176, which was used for the
latest 5.1 betas.

--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

Jani Taskinen

21 years ago

An ini file we might provide does not set the defaults.
Try running stuff without any php.ini file..

The error_reporting in a recommended (PHP 5.1!!!) ini
file should be at the "pedantic" level..

--Jani


On Sat, 18 Jun 2005, Daniel Convissor wrote:

> Hi Zeev:
>
> On Sat, Jun 18, 2005 at 12:59:31PM +0300, Zeev Suraski wrote:
>
>> Where do you see that?  As far as I can tell it certainly looks off by
>> default even in 5.1.
>
> http://cvs.php.net/php-src/php.ini-recommended#rev1.173
>
> That change is still in there as version 1.176, which was used for the
> latest 5.1 betas.
>
> --Dan
>
>

--
Donate @ http://pecl.php.net/wishlist.php/sniper

Rasmus Lerdorf

21 years ago

We can provide a suggested .ini for development purposes if you want,
but php.ini-recommended has display_errors off and various other
settings that are more geared to a production web server.  I see no
point in having pedantic warnings running on a production server.

-Rasmus

Jani Taskinen wrote:

Zeev Suraski

21 years ago

At 21:35 18/06/2005, Rasmus Lerdorf wrote:

>We can provide a suggested .ini for development purposes if you want,
>but php.ini-recommended has display_errors off and various other
>settings that are more geared to a production web server.  I see no
>point in having pedantic warnings running on a production server.

I agree.  That was the point of php.ini-recommended from the very beginning.

Zeev

Andi Gutmans

21 years ago

Thanks for spotting that. Not sure how it got in there.
I removed E_STRICT from the default error_reporting in php.ini-recommended.


At 01:24 PM 6/18/2005 +0100, Nicholas Telford wrote:

Jani Taskinen

21 years ago

Perhaps you should have noticed that the errors in php.ini-recommended
are logged so whatever the error level is shouldn't matter.

And I don't think this file is read-only everywhere? :)

--Jani

On Sat, 18 Jun 2005, Andi Gutmans wrote:

> Thanks for spotting that. Not sure how it got in there.
> I removed E_STRICT from the default error_reporting in php.ini-recommended.
>
>
> At 01:24 PM 6/18/2005 +0100, Nicholas Telford wrote:
>> Hello everyone,
>>
>> It seems that E_STRICT is on by default in php.ini-recommended as of 5.1
>>
>> I think the real issue here is nothing to do with E_STRICT being too strict,
>> it does what it says, and as Andi has already said, it's there as a means of
>> best practice checking for pedantic developers.
>>
>> The problem is that far too many people look at the distribution, see
>> "php.ini-recommended" and think that they should be using it, this isn't to
>> say that they shouldn't, but they should at least be aware that -recommended
>> means that everything is set up to be as tight as possible.
>>
>> I propose changing php.ini-recommended's error reporting level to simply
>> E_ALL. Those developers who require E_STRICT know how to turn it on and will
>> do so.
>>
>> I agree with Sara that E_STRICT could probably do with expanding, having it
>> simply checking for depreceated stuff is all well and good, but it's name
>> implies that it will alert the developer to anything not considered
>> strictly correct coding practice.
>>
>> Since this thread spawned off the one about adding public to PHP4.4, it's
>> probably not worth it, not due to backwards compatability (try running code
>> written for 4.3.x under 4.0.0...), but mostly because it'd effectively be
>> creating an intermediary branch between PHP 4 and PHP 5 that would be
>> neither one nor the other. It's probably just best to allow people to make
>> the move to PHP 5 over a longer period of time. Besides, as Andrey said, you
>> can just insert the keywords and have them commented out until the entire
>> app is ported.
>>
>> Sorry for the rather lengthy post, I've been watching these discussions with
>> great interest over the last few days and have only now had the chance to
>> post my thoughts.
>>
>> Nicholas Telford
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
Donate @ http://pecl.php.net/wishlist.php/sniper

Davey

21 years ago

Add a third php.ini, php.ini-dev

This should have the preferred settings for a development environment

- Davey

Jani Taskinen wrote: