On 24/10/06, Mathieu Gagné <[EMAIL PROTECTED]> wrote:
Hi,
> I personally also don't see a good reason to disable E_WARNING and
> E_NOTICE (and possibly also E_DEPRECATED) in a production environment -
> you may still want to log such errors. As long as display_errors is
> off, it's not a pr
Hi,
> I would consider this the sysadmin's fault for letting logs grow without
> bounds. Surely you have heard of log rotation?
These was not sysadmin's fault as it was the default Plesk setting.
Logrotate is enabled by default. But as the server was having a huge
load on it, daily logrotation
On 24-Oct-06, at 3:22 PM, Mathieu Gagné wrote:
]As a system administrator, I must disagree with your opinion as
most users don't care about error_log file. I have see a lot of
servers with about 6GB of error_log filled with E_NOTICE AND
E_WARNING.
Many ISPs often make 2 mistakes when it c
Mathieu Gagné wrote:
>> I personally also don't see a good reason to disable E_WARNING and
>> E_NOTICE (and possibly also E_DEPRECATED) in a production environment -
>> you may still want to log such errors. As long as display_errors is
>> off, it's not a problem except for the performance hit whi
Hi,
> I personally also don't see a good reason to disable E_WARNING and
> E_NOTICE (and possibly also E_DEPRECATED) in a production environment -
> you may still want to log such errors. As long as display_errors is
> off, it's not a problem except for the performance hit which should be
> low
On 24/10/06, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote:
Richard Quadling wrote:
> +1 - As an aside, it would be extremely useful to have the PEAR
> classes marked as NON strict (in some way) until they are. I know this
> is outside of the core, but using E_STRICT already means you have to
> to
Richard Quadling wrote:
+1 - As an aside, it would be extremely useful to have the PEAR
classes marked as NON strict (in some way) until they are. I know this
is outside of the core, but using E_STRICT already means you have to
toggle off E_STRICT for PEAR. MAYBE STRICT (e.g. strict class PEAR
{
My vote (if it counts - can someone let me know if it does?)
On 23/10/06, Marcus Boerger <[EMAIL PROTECTED]> wrote:
Hello internals,
after recent discussions (over the last three months)I finally made up my
mind over E_STRICT, deprecation warnings and OOP messages/rules. My idea
proposal is t
Wez Furlong wrote:
I don't think we need to set any firm ground rules for the deprecation
timeline but should consider each change individually. A reasonable
rule of thumb is to remove deprecated features no sooner than 1 minor
release after the deprecation notice was added. Ideally, it should
Derick Rethans wrote:
> On Tue, 24 Oct 2006, Edin Kadribasic wrote:
>> Writing mydb_fetch_object() becomes impossible in
>> userspace if we go this far. It would also make any legal use of
>> stdClass impossible.
>
> Yes, but in the "strict" world, there is no legal use for stdClass in
> the firs
On Tue, 24 Oct 2006, Edin Kadribasic wrote:
> Derick Rethans wrote:
> >> . E_STRICT any rule that reflects common strict standards, like OOP
> >> theory
> >> that is considered harmless if not followed. For example the
> >> combination
> >> 'abstract static' makes no sense in said theo
At 21:08 23/10/2006, Marcus Boerger wrote:
Hello internals,
after recent discussions (over the last three months)I finally made up my
mind over E_STRICT, deprecation warnings and OOP messages/rules. My idea
proposal is to do the following:
- Add a new severity E_DEPRECATED
- severities are u
On 10/23/06, Marcus Boerger <[EMAIL PROTECTED]> wrote:
. E_DEPRECATED: Some language featre that is likely to go away.
s/likely/confirmed/. We can't speculatively deprecate a feature and
then change our minds. (The {} vs [] thing with strings comes to
mind).
I don't think we need to set
Marcus Boerger wrote:
> - Add a new severity E_DEPRECATED
+1
> - severities are used as follows:
> . E_DEPRECATED: Some language featre that is likely to go away. Eearlierst
> removal would be two minor versions or one major version later. That is
> something that gets deprecated in 5.
Derick Rethans wrote:
>> . E_STRICT any rule that reflects common strict standards, like OOP theory
>> that is considered harmless if not followed. For example the combination
>> 'abstract static' makes no sense in said theory but doesn't put our zend
>> engine in an unstable state.
>
Marcus Boerger wrote:
> Hello internals,
>
> after recent discussions (over the last three months)I finally made up my
> mind over E_STRICT, deprecation warnings and OOP messages/rules. My idea
> proposal is to do the following:
>
> - Add a new severity E_DEPRECATED
>
> - severities are used a
Marcus Boerger wrote:
Hello internals,
after recent discussions (over the last three months)I finally made up my
mind over E_STRICT, deprecation warnings and OOP messages/rules. My idea
proposal is to do the following:
+1 to them all.
Alan
--
PHP Internals - PHP Runtime Development Mailing
On Mon, October 23, 2006 2:08 pm, Marcus Boerger wrote:
> Hello internals,
+1, ditto on only major version for E_DEPRECATED to disappear
I'd go either way on E_ALL changing -- but would think that the Right
Thing is to leave it alone in 5.2, but make it mean *ALL* (even
E_STRICT) in 6.0
--
Some
On 23-Oct-06, at 3:08 PM, Marcus Boerger wrote:
- Add a new severity E_DEPRECATED
- severities are used as follows:
. E_DEPRECATED: Some language featre that is likely to go away.
Eearlierst
removal would be two minor versions or one major version later.
That is
something that ge
On Mon, 23 Oct 2006, Marcus Boerger wrote:
> after recent discussions (over the last three months)I finally made up my
> mind over E_STRICT, deprecation warnings and OOP messages/rules. My idea
> proposal is to do the following:
>
> - Add a new severity E_DEPRECATED
+1
> - severities are used
Hi Marcus,
+1 to everything here if it counts, but please can you simplify the role of
E_DEPRECATED by making it 'next major version only'? I can see all kinds of
problems with leaving that open to debate.
- Steph
Hello internals,
after recent discussions (over the last three months)I fi
Hello internals,
after recent discussions (over the last three months)I finally made up my
mind over E_STRICT, deprecation warnings and OOP messages/rules. My idea
proposal is to do the following:
- Add a new severity E_DEPRECATED
- severities are used as follows:
. E_DEPRECATED: Some langua
22 matches
Mail list logo
