On 12-Jul-06, at 7:23 PM, Lukas Smith wrote:
Hosters are always behind 1 or 2 minor versions, at best.
That's an optimistic outlook, on average they are 5-6 versions behind.
Ilia Alshanetsky
Hello,
On 7/13/06, Lukas Smith <[EMAIL PROTECTED]> wrote:
Strict Standards: Declaration of Europe::get_countries() should be
compatible with that of Scandinavia::get_countries() in - on line 14
So I dont really see where its killing a fly with a tank either.
That's why I said it is killing a
Lukas Smith wrote:
Ok I see 2 options:
1)
Obviously one solution would be to disallow making anything an E_STRICT
notice that is not available since the first release of the given major
version.
Pierre and Anthony seem to favor this solution.
2)
Adding such a filter API into PHP internals h
Pierre wrote:
if foo-1.2.1 is E_STRICT compliant with 5.1.4 and foo-1.2.2 with
5.2.0, update to 1.2.2 must be the way. It is the safest way, the past
shown us that some E_STRICT can be related to (sometimes critical)
bugs and we should treat them as bugs. Also, I do not like the
additions of ped
Antony Dovgal wrote:
Well, that's what major versions are for, right?
Bugfix releases are for bugfixes, while major versions may introduce new
things and features.
Err we add features in minor (and even patch level) versions all the time.
Sorry, I still fail to see a reason to "filter" erro
On 13.07.2006 02:37, Lukas Smith wrote:
Antony Dovgal wrote:
Lukas, I thought we already discussed and agreed that the only
acceptable solution is NOT to add any E_STRICT messages if the
recommended way didn't exist in first release of the major version.
This apparently requires versioning an
Antony Dovgal wrote:
Lukas, I thought we already discussed and agreed that the only
acceptable solution is NOT to add any E_STRICT messages if the
recommended way didn't exist in first release of the major version.
This apparently requires versioning and its support in PEAR.
And personally I t
On 12.07.2006 19:56, Lukas Smith wrote:
Hi,
PEAR is currently in the process of deciding from when on we want to
mandate PHP5 as the target platform. Currently it looks like sometime in
the next 3-6 months we will likely only accept PHP5 only packages.
We are also pondering how to best appro
Why not just define your own custom error handler and have it filter
out the error messages that you don't want to see... To me this would
seem like a easier approach, i would be against adding a in-language
filter for this.
Ilia Alshanetsky
Hello,
On 7/12/06, Lukas Smith <[EMAIL PROTECTED]> wrote:
Adding such a filter API into PHP internals however seems like a
considerably effort. Therefore my proposal would be to simply add a
defined "header" to all E_STRICT messages that contains the PHP version
in which this E_STRICT message w
I have not dug super deep into this problem but it seems as though if I
try to call session_regenerate_id() after having set session.save_path
with custom values, i get an error. My guess is that
session_regenerate_id() is having issues with the save_path var.
This is my test script:
file: .
Hi,
PEAR is currently in the process of deciding from when on we want to
mandate PHP5 as the target platform. Currently it looks like sometime in
the next 3-6 months we will likely only accept PHP5 only packages.
We are also pondering how to best approach E_STRICT. It is not feasible
for us
Hi Andi,
Thanks for the reply. Yeah, array_fill_keys() may well make more sense. :-)
I had thought about that originally, and thought I came up with a reason to
just extend array_fill(), but I can't remember the reasoning now... (Maybe I
wasn't sure if you'd want another function.)
After your me
I think that error_get_last() makes sense, but not the other
two. You can fairly easily implement that using an error handler if
you'd like, and as Andi said, keeping track of all of the errors that
happened on a production server doesn't make sense from a performance
(and possibly even memory
14 matches
Mail list logo
