On Tue, Jul 31, 2012 at 11:55 PM, Lester Caine <les...@lsces.co.uk> wrote:
> Stas Malyshev wrote: > >> Helping to solve the problem would also help everybody else upgrade TO >>> PHP5.4? >>> >> OK, so what help do you require? >> > PEAR and PECL that work with PHP5.4 out of the box? > At least the core of PEAR that does not throw strict warnings from a stock > install of PHP5.4 as E_STRICT is on. > > > >Add to this the fun getting Apache 2.4 configured with PHP and my old >>> framework, >>> >it is no wonder I grumpy ... I would much rather be adding >>> functionality and >>> >working on NEW stuff than fixing the problems other people leave >>> behind. And I >>> >don't need any of the new PHP5.3/44 features to write my own new code. >>> >> While I can sympathize with your problems fixing bad code left by other >> people, I am not sure how it is relevant on this list - is there >> something that people present on this list can help you with? What is it? >> > > I think that this is the problem here. "fixing bad code" is simply not a > statement that I recognise! I am not fixing bad code, I am re-writing much > of it simply because the style is no longer acceptable, or somebody changed > a default setting without considering the consequences ( <?= not working in > PHP5.3 is STILL biting as ISP are only upgrading to PHP5.3! ) > Let me just throw this out there in case nobody's thought of it yet: Why don't we draft a clear policy (an RFC maybe?) with regard to how BC is handled with different version increments. Here's a rough sketch of what I'm proposing in terms of that policy: Version A.b.c A: Major version increment. We maintain the fundamental syntax and other defining characteristics of PHP, but everything else is fair game. We make it clear to all users that existing PHP scripts from previous A version increments are *not supported*. There is an understanding that, depending on your code, chances are you'll have to make at least some significant modifications to it. We will make every effort to document these behavioral differences. Because adoption is a gradual process anyway, people should have sufficient time to update their code before the majority of hosts make the switch, particularly if we document these in advance. b: Minor BC breaks can occur, but should be avoided when possible. If there is a BC issue, E_DEPRECATED should be used until the next b increment if at all possible to soften the impact. c: BC breaks should not occur here. Possible rare exception for critical/urgent bugfixes. This more or less mirrors what we seem to be doing already; indeed, maybe it already is documented somewhere? However, the fact that these arguments keep coming up makes me doubt that possibility. > I still have not had a proper answer to a question I repeatedly ask. > "Please can we have some tutorials on how 'strict' styling should be used?" > I'm fixing the warnings created but I still do not fully understand what I > am fixing. The main rework area has been not being able to use '$this' in > static functions, even if the function checks $this and defaults to the > static code internally. Adding 'public/private/protected/**static/self > ...' and using them in the right places is well documented in bits and > pieces, but there is no general 'how to' put the whole together? I suppose > someone will want to add traits and the rest to that, but just a simple > style guide for the basics would be nice ... +1 I don't know the answer, but it sounds to me like a perfectly reasonable question to ask. =) --Kris
