Now if we were really sneaky, we'd make E_DEVEL visible in 'lint mode'
only...
At 03:02 PM 5/30/2006, Marcus Boerger wrote:
whatever the patch looks like, it is a change from 5.0.0's
E_STRICT
to aE_COMPILE_ERRORand actually fixes another problem. This raises
an interesting question. How long must we wait until we can follow the
E_STRICT idea and change a specificE_STRICTinto a fatal error. Must
it be until eternity?
E_STRICTdoesn't mean that those warnings will become errors down the
road. It just enforces best practices, and some might deprecate and some
might not...Now that's why I suggested E_DEVEL for 'advisory' issues. The problem is
that E_STRICT, according to the manual and most of the dev team, is only
there for 'real' deprecation issues.
- Steph
Andi
I think E_STRICT the way it is, is good enough. We don't need to make
it even more confusing by having lots of additional error levels. We
do mention in some E_STRICT msgs that things are deprecated
"Deprecated: ...". Some things are just best practices... Let's not
over complicate this and have a gazillion of error msgs.
At 07:14 PM 5/30/2006, Steph Fox wrote:
Now if we were really sneaky, we'd make E_DEVEL visible in 'lint
mode' only...At 03:02 PM 5/30/2006, Marcus Boerger wrote:
whatever the patch looks like, it is a change from 5.0.0's
E_STRICT
to aE_COMPILE_ERRORand actually fixes another problem. This raises
an interesting question. How long must we wait until we can follow the
E_STRICT idea and change a specificE_STRICTinto a fatal error. Must
it be until eternity?E_STRICT doesn't mean that those warnings will become errors down
the road. It just enforces best practices, and some might
deprecate and some might not...Now that's why I suggested E_DEVEL for 'advisory' issues. The
problem is that E_STRICT, according to the manual and most of the
dev team, is only there for 'real' deprecation issues.
- Steph
Andi