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
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
Zeev Suraski wrote:
Ilia,
I think Wez's suggestion is the most practical one. Let's make sure we
haven't introduced any fatal errors into 5.2 (and demote them to
E_STRICT for now), and handle the rest of the suggestions afterwards.
+1
I guess this is the best we can go. It might cause some
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
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
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
{
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
For this particular purpose there is a fairly detailed
README.UPDATE_5_2 that details the major functionality changes that
have happened in PHP 5.2
On 24-Oct-06, at 12:17 AM, Lester Caine wrote:
Ilia Alshanetsky wrote:
I've been reading people's replies to Marcus' RFC in regard to
E_DEPR
Zeev,
There are probably 5-6 new fatal errors in the engine since 5.1, some
of which cannot be delegated to lower error reporting modes as they
may cause engine instability or similar problems. Rasmus was going to
make a list of all the newly added engine error changes, hopefully
he'll ha
Ilia Alshanetsky wrote:
Zeev,
There are probably 5-6 new fatal errors in the engine since 5.1, some of
which cannot be delegated to lower error reporting modes as they may
cause engine instability or similar problems. Rasmus was going to make a
list of all the newly added engine error changes
Well I'm definitely not referring to those, only the new strict OO
fatals as per Marcus's original message...
Zeev
At 16:32 24/10/2006, Ilia Alshanetsky wrote:
Zeev,
There are probably 5-6 new fatal errors in the engine since 5.1, some
of which cannot be delegated to lower error reporting mod
On 10/24/06, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
Zeev,
There are probably 5-6 new fatal errors in the engine since 5.1, some
of which cannot be delegated to lower error reporting modes as they
may cause engine instability or similar problems. Rasmus was going to
make a list of all the ne
I think that a lot of those are legit - we only need to 'demote' the
language-level warnings/errors that attempt to enforce strict OO standards.
Warnings/errors that warn about unacceptable input are legitimate and
should stay.
Zeev
At 16:57 24/10/2006, Hannes Magnusson wrote:
On 10/24/06, Il
Some OO errors like using iterators by reference and throwing
exceptions out of __toString() are ligit as well, doing so would/
could cause problems.
On 24-Oct-06, at 11:10 AM, Zeev Suraski wrote:
I think that a lot of those are legit - we only need to 'demote'
the language-level warnings/
Right.
Zeev
At 17:13 24/10/2006, Ilia Alshanetsky wrote:
Some OO errors like using iterators by reference and throwing
exceptions out of __toString() are ligit as well, doing so would/
could cause problems.
On 24-Oct-06, at 11:10 AM, Zeev Suraski wrote:
I think that a lot of those are leg
Hello Ilia,
both, the __toString and the iterator in foreach by reference would put
the engine into an unstable state. That saiditis very important that we do
not blindley change error modes here. Most changes havebeen done for a good
reason. And most of those were added lately because we are al
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
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
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
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
Hi,
First my apologies for not being able to go a real reply to the real thread,
but I just subscribed to the list a couple days ago (and the original thread
subject was way too long anyway ;-)).
> > Boolean values are the only case where it is not possible to
> > distinguish FALSE from inval
21 matches
Mail list logo
