Hi!
(Apologies for starting a new thread.)
I compiled 5.2.5 last night and noticed that it effectively breaks all
static calls which have no static keyword assigned in the function's
definition (sorry, a bit clumsy here). I thought this had been
discussed before and was due to 5.3 but then it had been decided to
move this into E_STRICT (again) and wait off with the major BC break
for PHP6. Apparently I perceived wrong, none the less I believe this
needs to be fixed (= removed) ASAP.
Reason is - this breaks a dozen apps out there, and while I certainly
agree with everyone that those apps and scripts need to be updated -
the reality is that it will take some time. It would be sufficient if
PHP6 announces such a major break, I don't see how a "minor" release
like PHP 5.2.5 can do this. Especially since it worked (including
E_STRICT) in 5.2.3 (and I believe 5.2.4 also).
I see all the technical reasons and quite frankly - they don't matter here.
PHP relies on a user base which is not strictly technical. The
adoption of PHP does not just come from its great concept and ease of
learning but also due to hard facts - such as, there are CMS, gallery
scripts, blogs, webmails and forums which people want to use. Those
people don't care why their app doesn't work when you change from
5.2.x to another 5.2.x. Effectively this means more FUD about moving
to PHP5 is spread and people stay with PHP4 a lot longer because PHP5
for them is totally unpredictable.
I can totally see how you can translate it for them that it breaks
when you switch from 4 to 5, or even 5 to 6 - hell, especially 4 to 6.
But not in what I would consider a minor version (minor in regard to
the version number).
Last but not least - is there anything (a compile flag, etc.) one can
disabled now to "fix" this issue? Or do you suggest a rollback to
5.2.4 (or 5.2.3)?
Thanks,
Till
P.S.
Please CC me on your replies.
Hello till,
we changed the behavior as much back as we need be. Fact is that this has
been an oversight. It has been a bug we just fixed. As an eagreement we
decided not to mark all of these as fatal. We might do so in later versions.
However we have been mentioning this for years now. Fix the damn code. If
you are not willing to do so, then imo you should just stick with older
versions.
Saturday, March 1, 2008, 8:15:49 PM, you wrote:
Hi!
(Apologies for starting a new thread.)
I compiled 5.2.5 last night and noticed that it effectively breaks all
static calls which have no static keyword assigned in the function's
definition (sorry, a bit clumsy here). I thought this had been
discussed before and was due to 5.3 but then it had been decided to
move this intoE_STRICT(again) and wait off with the major BC break
for PHP6. Apparently I perceived wrong, none the less I believe this
needs to be fixed (= removed) ASAP.
Reason is - this breaks a dozen apps out there, and while I certainly
agree with everyone that those apps and scripts need to be updated -
the reality is that it will take some time. It would be sufficient if
PHP6 announces such a major break, I don't see how a "minor" release
like PHP 5.2.5 can do this. Especially since it worked (including
E_STRICT) in 5.2.3 (and I believe 5.2.4 also).
I see all the technical reasons and quite frankly - they don't matter here.
PHP relies on a user base which is not strictly technical. The
adoption of PHP does not just come from its great concept and ease of
learning but also due to hard facts - such as, there are CMS, gallery
scripts, blogs, webmails and forums which people want to use. Those
people don't care why their app doesn't work when you change from
5.2.x to another 5.2.x. Effectively this means more FUD about moving
to PHP5 is spread and people stay with PHP4 a lot longer because PHP5
for them is totally unpredictable.
I can totally see how you can translate it for them that it breaks
when you switch from 4 to 5, or even 5 to 6 - hell, especially 4 to 6.
But not in what I would consider a minor version (minor in regard to
the version number).
Last but not least - is there anything (a compile flag, etc.) one can
disabled now to "fix" this issue? Or do you suggest a rollback to
5.2.4 (or 5.2.3)?
Thanks,
Till
P.S.
Please CC me on your replies.
Best regards,
Marcus
Hi Marcus,
we changed the behavior as much back as we need be. Fact is that this has
been an oversight. It has been a bug we just fixed. As an eagreement we
decided not to mark all of these as fatal.
Why are any of them fatal?
- Steph
Hello till,
we changed the behavior as much back as we need be. Fact is that this has
been an oversight. It has been a bug we just fixed. As an eagreement we
decided not to mark all of these as fatal. We might do so in later versions.
However we have been mentioning this for years now. Fix the damn code. If
you are not willing to do so, then imo you should just stick with older
versions.
Hey Markus,
thank you. So are you guys gonna re-release a 5.2.5 or 5.2.6, what's the plan?
Btw, is there anything one can do to get more involved and spot those issues?
I agree that the code needs to be fixed. I also think you can't break
BC in a minor version. But generally I totally agree that it's time to
move on.
Till
Hello till,
lukas has a primary tester list. If you have an application that is used
by a lot of people and not just by you, you should contact him. You can
also subscribe to the QA list. Further more no one is hindering from
testing PHP during development...
marcus
Saturday, March 1, 2008, 8:45:56 PM, you wrote:
Hello till,
we changed the behavior as much back as we need be. Fact is that this has
been an oversight. It has been a bug we just fixed. As an eagreement we
decided not to mark all of these as fatal. We might do so in later versions.
However we have been mentioning this for years now. Fix the damn code. If
you are not willing to do so, then imo you should just stick with older
versions.
Hey Markus,
thank you. So are you guys gonna re-release a 5.2.5 or 5.2.6, what's the plan?
Btw, is there anything one can do to get more involved and spot those issues?
I agree that the code needs to be fixed. I also think you can't break
BC in a minor version. But generally I totally agree that it's time to
move on.
Till
Best regards,
Marcus
Btw, is there anything one can do to get more involved and spot those issues?
http://news.php.net/php.pear.qa/4812
-Hannes
On Sat, Mar 1, 2008 at 8:51 PM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:
Btw, is there anything one can do to get more involved and spot those issues?
Guess I need to change my subscribtion settings to pear-qa (to not
only receive digest ;-)).
Thanks,
Till
Hi Marco,
Hello till,
we changed the behavior as much back as we need be. Fact is that this has
been an oversight. It has been a bug we just fixed. As an eagreement we
decided not to mark all of these as fatal. We might do so in later versions.
However we have been mentioning this for years now. Fix the damn code. If
you are not willing to do so, then imo you should just stick with older
versions.
On a case by case basis, the code may be fixed, we all agree on that.
But this answer is not acceptable. Can you seriously ask someone to
stick to versions with security fixes only because of our strictness
breakages? I can accept (does not mean that I agree) a change to fatal
between 5.2 to 5.3 for example- But it must not happen between two
patches releases (I say must instead of should, as it is a must to do
break code in this case).
Cheers,
Hello Pierre,
Saturday, March 1, 2008, 8:53:26 PM, you wrote:
and yeas after several years of trying to communicate and never gotten
anything back? I have told PREAR development a million times to fix code.
Now not even PEAR code is wrong but it is copied into endless amounts of
code. So it seems ignorance is bliss is what our userbase is doing. So I
need to do the same, no? On the other hand Rasmus and I spent a lot time
getting this right without affecting users to much and we infact did
encounter things that lead to bigger issues and I am not introducing tons
of workarounds.
marcus
My name is Marcus
Hi Marco,
Hello till,
we changed the behavior as much back as we need be. Fact is that this has
been an oversight. It has been a bug we just fixed. As an eagreement we
decided not to mark all of these as fatal. We might do so in later versions.
However we have been mentioning this for years now. Fix the damn code. If
you are not willing to do so, then imo you should just stick with older
versions.
On a case by case basis, the code may be fixed, we all agree on that.
But this answer is not acceptable. Can you seriously ask someone to
stick to versions with security fixes only because of our strictness
breakages? I can accept (does not mean that I agree) a change to fatal
between 5.2 to 5.3 for example- But it must not happen between two
patches releases (I say must instead of should, as it is a must to do
break code in this case).
Cheers,
Best regards,
Marcus
Hello Pierre,
Saturday, March 1, 2008, 8:53:26 PM, you wrote:
and yeas after several years of trying to communicate and never gotten
anything back? I have told PREAR development a million times to fix code.
I don't know PREAR and don't care about PEAR. This issues does not
create troubles only for PEAR but to many applications out there, open
sources or not. Users love to update to the next point release (often
for security reason or crashes) and likes when their applications
continue to work just like before.
Now not even PEAR code is wrong but it is copied into endless amounts of
code. So it seems ignorance is bliss is what our userbase is doing. So I
need to do the same, no? On the other hand Rasmus and I spent a lot time
getting this right without affecting users to much and we infact did
encounter things that lead to bigger issues and I am not introducing tons
of workarounds.
Again, focusing on PEAR being <put everything bad you think about it
here> does not matter. And again, I'm not arguing about the needs of
fixing bugs but about pointless fatal errors introductions (or
anything else higher than a notice) in point releases. I think it is
understandable.
Anyway, you know my opinion as we discussed this problem hundred of
times already.
Cheers,
Bjori just nailed it:
class foo { function foo() { echo 'foo'; } }
foo::foo();
It's some constructor BC thing.
till wrote:
Bjori just nailed it:
class foo { function foo() { echo 'foo'; } }
foo::foo();It's some constructor BC thing.
I didn't think any of these changes were in the 5_2 tree at all. As far
as I am concerned the E_STRICT is for 5.3. We can't make a change like
this in a minor version bump.
-Rasmus
Marcus Boerger wrote:
Hello Pierre,
Saturday, March 1, 2008, 8:53:26 PM, you wrote:
and yeas after several years of trying to communicate and never gotten
anything back? I have told PREAR development a million times to fix code.
Now not even PEAR code is wrong but it is copied into endless amounts of
code. So it seems ignorance is bliss is what our userbase is doing. So I
need to do the same, no? On the other hand Rasmus and I spent a lot time
getting this right without affecting users to much and we infact did
encounter things that lead to bigger issues and I am not introducing tons
of workarounds.
Hi Marcus,
Holy cow my friend. You know full well that PEAR has been actively
working on an installer for PHP 5.3+, and also know full well that the
existing PEAR installer supports actual users, the majority of whom use
PHP 5.2+, but a significant minority (read thousands) still use PHP 4 on
a daily basis. We have the same upgrade problems that PHP does - some
unix distributions are still distribution PEAR 1.2 with PHP 4 by
default, and Mac OS X bundled (until recently) a really old version of
PEAR 1.3 (we've been at 1.7 for a few months now, for context).
Perhaps a little understanding of the real world would be helpful here:
people who use PEAR expect it to work with the minimum PHP supported
version, which in our case is PHP 4.3.
You also know for a fact that I have no love for PHP 4, and haven't
actually used it for years, but every time some PHP 4-related issue
creeps in, we get bug reports immediately. PEAR serves its users, period.
Can we move on from this ridiculous recurring religious debate over
nothing and please never mention it again?
Thank you,
Greg
I compiled 5.2.5 last night and noticed that it effectively breaks all
static calls which have no static keyword assigned in the function's
definition (sorry, a bit clumsy here). ....
How about waiting to break people's :: calls to non-static functions
until some number of releases or amount of time after traits are
introduced? For years, making :: calls to non-static functions has
been the php way to write traits. (OK, this lacks a lot of the
features of full traits, but it's better than nothing.) Isn't it
fair to provide an alternative and some time to switch to the
alternative before making the old way fatal?
In case it isn't clear how you could write a trait, here's a
silly example: (A full example would have more interesting code
that would be re-used by a variety of objects, but this example
demonstrates the key abilities of php without the distractions
of doing something useful.)
<?php
class Trait {
function e() {
print $this->g()."\n";
}
function f() {
Trait::e();
}
}
class Obj {
function g() {
return 5;
}
function h() {
Trait::f();
}
}
$o = new Obj;
$o->h();
?