Re: [PHP-DEV] Core liason for PHP FIG
Kris Craig wrote: Steering things back to the original topic, my objections to collaboration with FIG seem to be pretty much centered around their edictal approach to userland style guidelines and how our involvement could be construed as an endorsement of said style. If they would agree to make some modifications to this approach, I'd probably be able to withdraw my objection entirely. I don't see how that is any different to what *I* said? So why do I get clobbered for explaining what my objections are to their setup? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Core liason for PHP FIG
Hi! Steering things back to the original topic, my objections to collaboration with FIG seem to be pretty much centered around their edictal approach to userland style guidelines and how our involvement could be construed as an endorsement of said style. If they would agree to make some modifications to this approach, I'd probably be able to withdraw my objection entirely. Any standards group would have edictal approach. That's the point of standard - it prescribes a way of doing something. You may follow it or not, but if it doesn't do that it's not a standard. Now, I do not know if such standards will be successful in PHP world. But I think it's a good idea to try and see if people adopt it. Probably some things should have some standards - even if just to describe some common things - it's much easier to say we follow standard X than to have 10-page description of the coding style and trying to figure out if it's the same as another 10-page description or not. As for having php.net representative, I'm not sure if it is needed since I'm not sure what is the purpose of it. If it's just having a vote, I don't think it makes a lot of sense - php.net is not a PHP framework and does not represent any frameworks, and is to serve any of them and all of them and all non-framework developers equally. If it's to provide some expertise or answers to core/internals question, this can be done by anybody on the list without designating any special person. If it would serve some other purpose, I think additional explanation is needed. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Core liason for PHP FIG
On Mon, Dec 17, 2012 at 4:36 AM, Stas Malyshev smalys...@sugarcrm.comwrote: As for having php.net representative, I'm not sure if it is needed since I'm not sure what is the purpose of it. If it's just having a vote, I don't think it makes a lot of sense - php.net is not a PHP framework and does not represent any frameworks, and is to serve any of them and all of them and all non-framework developers equally. If it's to provide some expertise or answers to core/internals question, this can be done by anybody on the list without designating any special person. If it would serve some other purpose, I think additional explanation is needed. If there was anything at all in this entire thread worth reading it was probably these few lines. Well said :) -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Core liason for PHP FIG
On Sun, Dec 16, 2012 at 1:02 AM, Lars Strojny l...@strojny.net wrote: Hello everybody, for all of you who don’t know, PHP FIG (Framework Interoperability Group, http://www.php-fig.org/) discusses ways frameworks and libraries can work together and integrate much easier. Current PSRs are PSR-0 to standardize autoloading, PSR-1 and PSR-2 that deal with coding styles. All three are great initiatives so far in bridging gaps between projects and making the PHP ecosystem, well, rounder. PHP core currently doesn’t have a vote in that group and I think this is something we should change. Is anybody interested in taking part of the discussions there and representing PHP core? cu, Lars -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php My one concern with this idea is that it could give the erroneous impression that the coding style standards your group advocates are endorsed, implicitly or otherwise, by the PHP Group. There is no official standard when it comes to spaces vs. tabs and whether to place brackets on the same line, for example. Given how many different competing standards there are out there, I fear that we could run the risk of showing favoritism by legitimizing one standards group but not others. Personally, and I'm just speaking for myself here, I think you guys over-reached with your PSR-2 style guidelines. I totally agree with your goal of aiding consistency, but these standards are inherently arbitrary and it makes me very uneasy to see anyone proclaim that such-and-such is the correct style of doing something in PHP. The only solution I can see is to create several different style rulesets to reflect all the noteworthy styles in popular use. Of course, then you run the risk of undermining the whole consistency goal. I think XKCD put it best: http://xkcd.com/927/ I wouldn't be adverse to us linking to your project, so long as we do the same for any others that crop-up and we make it clear that these third-party standards are not officially endorsed by the PHP Group. I also think it's cool if anyone here wants to join your project and contribute, so long as that person is representing him/her self. That's my take on this. --Kris
Re: [PHP-DEV] Core liason for PHP FIG
Hi Kris, thanks for your response. Just a short note: I'm not in any ways officially related to PHP FIG, except that I find it personally to be a good initiative. Rest of the answers below. Am 16.12.2012 um 11:50 schrieb Kris Craig kris.cr...@gmail.com: My one concern with this idea is that it could give the erroneous impression that the coding style standards your group advocates are endorsed, implicitly or otherwise, by the PHP Group. There is no official standard when it comes to spaces vs. tabs and whether to place brackets on the same line, for example. Given how many different competing standards there are out there, I fear that we could run the risk of showing favoritism by legitimizing one standards group but not others. I see what you mean. On the other hand though, a majority of important PHP projects are organized there. We (as core developers) can’t ignore what these projects are discussing and I don't think we should. And if we have a saying in that, why shouldn’t we endorse such an initiative. Personally, and I'm just speaking for myself here, I think you guys over-reached with your PSR-2 style guidelines. I totally agree with your goal of aiding consistency, but these standards are inherently arbitrary and it makes me very uneasy to see anyone proclaim that such-and-such is the correct style of doing something in PHP. The only solution I can see is to create several different style rulesets to reflect all the noteworthy styles in popular use. Of course, then you run the risk of undermining the whole consistency goal. I, again, can’t speak for PHP FIG, but it seems to me like the survey technique worked out pretty well. So PSR-1 and PSR-2 are what most projects are doing anyway. I wouldn't be adverse to us linking to your project, so long as we do the same for any others that crop-up and we make it clear that these third-party standards are not officially endorsed by the PHP Group. I also think it's cool if anyone here wants to join your project and contribute, so long as that person is representing him/her self. See point above. We can’t ignore what major players in the ecosystem do and I don't think we should. I would much rather see PHP core have a saying in their decisions than standing by the lines and letting things happen (which might even be counter-productive for core). cu, Lars -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Core liason for PHP FIG
hi Lars, On Sun, Dec 16, 2012 at 10:02 AM, Lars Strojny l...@strojny.net wrote: PHP core currently doesn’t have a vote in that group and I think this is something we should change. Is anybody interested in taking part of the discussions there and representing PHP core? My take on this story is more the other way round. FIG is made of individuals, not really project based. These individuals obviously participate to many projects. Sadly not very often to the core. PHP core should get more contributors/contributuons from the numerous leading projects out there. As soon as one regularly contributes to the core, he will get the voting karma. This is something we have seen in the past, legacy core developers were not really in sync with the community needs or wishes. That's why we need them to work with the core instead of the other way 'round. It will create more bridges between FIG, the various leading PHP projects and the language development and design. Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Core liason for PHP FIG
Hi Pierre, Am 16.12.2012 um 13:08 schrieb Pierre Joye pierre@gmail.com: This is something we have seen in the past, legacy core developers were not really in sync with the community needs or wishes. That's why we need them to work with the core instead of the other way 'round. It will create more bridges between FIG, the various leading PHP projects and the language development and design. I couldn’t agree more, this is and was a problem. Still, the modus operandi of PHP FIG is people representing projects and I don’t see any core developers participating there (which is obviously nobodies fault). If nobody else is interested, would anybody object me representing core at PHP FIG? cu, Lars -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Core liason for PHP FIG
Lars Strojny wrote: for all of you who don’t know, PHP FIG (Framework Interoperability Group,http://www.php-fig.org/) discusses ways frameworks and libraries can work together and integrate much easier. Current PSRs are PSR-0 to standardize autoloading, PSR-1 and PSR-2 that deal with coding styles. All three are great initiatives so far in bridging gaps between projects and making the PHP ecosystem, well, rounder. Well I'm already classed as a dinosaur, but I have been requesting a guide to writing code these days, however some of the MUST elements of PSR-2 are totally opposite to the style guide that I have worked with for years and I see no point in arbitrary having to restyle 10+ years of code. Trying to restyle for e_strict is bad enough. As an example ... Code MUST use 4 spaces for indenting, not tabs. WHY - tab's has been the standard for all my C/C++ code and every other language and is automatically tidied up to that format by my editor. When did a switch of this 'rule' come in? Or is there a plan to switch all of the core code base to follow the same rule? ;) At the end of the day PHP FIG is simply an example of one style of working. It is perhaps the style that many developments in core are following as well? But it not the only way of working? Personally I prefer to avoid 'magic loading of files' and stick with specifying what files are load and from where. Avoids problems with different distributions changing the rules themselves! I see no hope of promoting a 'flat platform' staring point, since each distribution loves to promote it's own style of working, and running PHP on top of THEIR version of the world makes some standards academic? Where ARE files loaded tends to be the first problem when debugging a new distribution :( -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Core liason for PHP FIG
You realize that this is not the list of PHP FIG, right? On 16 December 2012 15:26, Lester Caine les...@lsces.co.uk wrote: Lars Strojny wrote: for all of you who don’t know, PHP FIG (Framework Interoperability Group,http://www.php-fig.org/) discusses ways frameworks and libraries can work together and integrate much easier. Current PSRs are PSR-0 to standardize autoloading, PSR-1 and PSR-2 that deal with coding styles. All three are great initiatives so far in bridging gaps between projects and making the PHP ecosystem, well, rounder. Well I'm already classed as a dinosaur, but I have been requesting a guide to writing code these days, however some of the MUST elements of PSR-2 are totally opposite to the style guide that I have worked with for years and I see no point in arbitrary having to restyle 10+ years of code. Trying to restyle for e_strict is bad enough. As an example ... Code MUST use 4 spaces for indenting, not tabs. WHY - tab's has been the standard for all my C/C++ code and every other language and is automatically tidied up to that format by my editor. When did a switch of this 'rule' come in? Or is there a plan to switch all of the core code base to follow the same rule? ;) At the end of the day PHP FIG is simply an example of one style of working. It is perhaps the style that many developments in core are following as well? But it not the only way of working? Personally I prefer to avoid 'magic loading of files' and stick with specifying what files are load and from where. Avoids problems with different distributions changing the rules themselves! I see no hope of promoting a 'flat platform' staring point, since each distribution loves to promote it's own style of working, and running PHP on top of THEIR version of the world makes some standards academic? Where ARE files loaded tends to be the first problem when debugging a new distribution :( -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- hype WWW: plphp.dk / plind.dk CV: careers.stackoverflow.com/peterlind LinkedIn: plind Twitter: kafe15 /hype -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Core liason for PHP FIG
hi Lars, On Sun, Dec 16, 2012 at 1:20 PM, Lars Strojny l...@strojny.net wrote: Hi Pierre, Am 16.12.2012 um 13:08 schrieb Pierre Joye pierre@gmail.com: This is something we have seen in the past, legacy core developers were not really in sync with the community needs or wishes. That's why we need them to work with the core instead of the other way 'round. It will create more bridges between FIG, the various leading PHP projects and the language development and design. I couldn’t agree more, this is and was a problem. Still, the modus operandi of PHP FIG is people representing projects and I don’t see any core developers participating there (which is obviously nobodies fault). If nobody else is interested, would anybody object me representing core at PHP FIG? Nobody will object if you join this group, however I do not see how anyone could represent php.net. The PHP group could be there, but I don't see that happening anytime soon, not very representative anymore either. If there is something that should be implemented in core, coming from the FIG, then a RFC should be written, discussed and proposed. That's the right and easy way. Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Core liason for PHP FIG
Lars, On Sun, Dec 16, 2012 at 3:26 PM, Lester Caine les...@lsces.co.uk wrote: snip Once again this is totally off base. We are not discussing anything proposed or adopted by the FIG group but how php.net can better cooperate with this group. I urge you to stay on topic and move any other topics to the right place. -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Core liason for PHP FIG
Pierre Joye wrote: On Sun, Dec 16, 2012 at 3:26 PM, Lester Caineles...@lsces.co.uk wrote: snip Once again this is totally off base. We are not discussing anything proposed or adopted by the FIG group but how php.net can better cooperate with this group. I urge you to stay on topic and move any other topics to the right place. Actually the question is perfectly valid ... why do we standardise on using TAB in the core code, but then use spaces in the php files? It would seem that FIG group standards have been adopted in some areas of PHP when the real standard is something different? I've just realised why I have been having problems with some area which USED to use the TAB standard but which have been switched to 'spaces' instead! So what IS the standard for file style in core code files? While ignoring white space on comparisons does work, it also results in problems when trying to commit changes to files which are using different white space standards. OK - scanning a few more files it would seem that spaces are an exception (fetch.php for example), and I've found the guideline calling for tab rather than spaces, but does that guideline apply transparently to .php files as well? Certainly .phpt files are consistently tabbed. It's not the only difference that FIG are pushing which is opposite to the style standards on the core code, so perhaps we should be lobbying them to come in line with the documented standards? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Core liason for PHP FIG
On Sun, Dec 16, 2012 at 7:46 PM, Lester Caine les...@lsces.co.uk wrote: Pierre Joye wrote: On Sun, Dec 16, 2012 at 3:26 PM, Lester Caineles...@lsces.co.uk wrote: snip Once again this is totally off base. We are not discussing anything proposed or adopted by the FIG group but how php.net can better cooperate with this group. I urge you to stay on topic and move any other topics to the right place. Actually the question is perfectly valid ... why do we standardise on using TAB in the core code, but then use spaces in the php files? It would seem that FIG group standards have been adopted in some areas of PHP when the real standard is something different? I've just realised why I have been having problems with some area which USED to use the TAB standard but which have been switched to 'spaces' instead! So what IS the standard for file style in core code files? While ignoring white space on comparisons does work, it also results in problems when trying to commit changes to files which are using different white space standards. OK - scanning a few more files it would seem that spaces are an exception (fetch.php for example), and I've found the guideline calling for tab rather than spaces, but does that guideline apply transparently to .php files as well? Certainly .phpt files are consistently tabbed. It's not the only difference that FIG are pushing which is opposite to the style standards on the core code, so perhaps we should be lobbying them to come in line with the documented standards? We done a survey on all the major projects and what their standards were and went with the majority of what already existed. It doesn't matter what we at FIG as long as it was consistent. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=**contacthttp://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.**ukhttp://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Core liason for PHP FIG
Paul Dragoonis wrote: It's not the only difference that FIG are pushing which is opposite to the style standards on the core code, so perhaps we should be lobbying them to come in line with the documented standards? We done a survey on all the major projects and what their standards were and went with the majority of what already existed. It doesn't matter what we at FIG as long as it was consistent. But adopting standards that are NOT consistent with the well documented standards of the core code just seems wrong? It is CREATING more problems since it's perpetuating a 'mistake' which should have been fix instead. My own example on that is libraries that were perfectly tidy 'tabbed' code have now be rewritten with spaces, to bring them in line with 'the standard', but also making them incompatible with the what has always been the documented standard ... using tabs! My own code base was perfectly clean tabbed code, and anything I commit will follow that standard, but new versions of libraries are now appearing with spaces :( At least ADOdb is still tabbed code :) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Core liason for PHP FIG
Anthony Ferrara wrote: can we please keep superfluous discussions like coding standards off-list? I have no issue with representation of fig discussion, but whitespace discussions have no place on this list... The standards being dictated by FIG are at odds with those adopted here for many years? So should we be asking them to change the standard to comply with already documented standards, or alternatively should we be bowing to their proposals and rewriting the core standards? So the discussion should be Do we accept that they are a legitimate standards authority? or simply ask them to indicate that they ARE at odds with the existing adopted standards? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Core liason for PHP FIG
On 12/16/2012 12:27 PM, Lester Caine wrote: Anthony Ferrara wrote: can we please keep superfluous discussions like coding standards off-list? I have no issue with representation of fig discussion, but whitespace discussions have no place on this list... The standards being dictated by FIG are at odds with those adopted here for many years? So should we be asking them to change the standard to comply with already documented standards, or alternatively should we be bowing to their proposals and rewriting the core standards? So the discussion should be Do we accept that they are a legitimate standards authority? or simply ask them to indicate that they ARE at odds with the existing adopted standards? Lester, please stop arguing every point here. Especially really silly stuff like this. These are not even the same languages. The main core coding standards are all about C-specific things like freeing memory, zero-terminated strings, never using strncat, macro usage, preprocessor usage, internal naming, C-commenting, KR style stuff, testing, folding, and yes there is a single line about tabs vs. spaces which is the one thing you zeroed in on and could possibly apply to both C code and PHP code, but the fact is that the core coding standards have nothing to do with user-space PHP coding standards and were written specifically to apply to the PHP core code written in C. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Core liason for PHP FIG
Hi Lars, Thanks for your detailed response. My thoughts inline below --Kris On Sun, Dec 16, 2012 at 3:42 AM, Lars Strojny l...@strojny.net wrote: Hi Kris, thanks for your response. Just a short note: I'm not in any ways officially related to PHP FIG, except that I find it personally to be a good initiative. Rest of the answers below. Am 16.12.2012 um 11:50 schrieb Kris Craig kris.cr...@gmail.com: My one concern with this idea is that it could give the erroneous impression that the coding style standards your group advocates are endorsed, implicitly or otherwise, by the PHP Group. There is no official standard when it comes to spaces vs. tabs and whether to place brackets on the same line, for example. Given how many different competing standards there are out there, I fear that we could run the risk of showing favoritism by legitimizing one standards group but not others. I see what you mean. On the other hand though, a majority of important PHP projects are organized there. We (as core developers) can’t ignore what these projects are discussing and I don't think we should. And if we have a saying in that, why shouldn’t we endorse such an initiative. Here's the problem: Who decides what constitutes an important PHP project? And as for the minority of important projects, do we then say to them that the standards they've chosen to adopt are invalid now? I fear that that's the message we'd be sending, perhaps unintentionally, if php.netin any way officially endorsed this group. I like the idea of consistency, but I believe php.net should remain neutral when it comes to userland PHP coding style. Personally, and I'm just speaking for myself here, I think you guys over-reached with your PSR-2 style guidelines. I totally agree with your goal of aiding consistency, but these standards are inherently arbitrary and it makes me very uneasy to see anyone proclaim that such-and-such is the correct style of doing something in PHP. The only solution I can see is to create several different style rulesets to reflect all the noteworthy styles in popular use. Of course, then you run the risk of undermining the whole consistency goal. I, again, can’t speak for PHP FIG, but it seems to me like the survey technique worked out pretty well. So PSR-1 and PSR-2 are what most projects are doing anyway. Most important projects, that is. But even if we accept that standard, completely ignoring less common but still prevelant standards is a deal-breaker for me. If FIG wants to become the accepted standards authority, then they will have to represent *everyone*, not just the majority or those whom they deem to be important. I wouldn't be adverse to us linking to your project, so long as we do the same for any others that crop-up and we make it clear that these third-party standards are not officially endorsed by the PHP Group. I also think it's cool if anyone here wants to join your project and contribute, so long as that person is representing him/her self. See point above. We can’t ignore what major players in the ecosystem do and I don't think we should. I would much rather see PHP core have a saying in their decisions than standing by the lines and letting things happen (which might even be counter-productive for core). Since FIG is not a universally accepted authority, I see no point in us getting involved. If later on it incorporates other standards and gains prevailing legitimacy throughout the userland community, then I might be more open to the idea.
Re: [PHP-DEV] Core liason for PHP FIG
Rasmus Lerdorf wrote: On 12/16/2012 12:27 PM, Lester Caine wrote: Anthony Ferrara wrote: can we please keep superfluous discussions like coding standards off-list? I have no issue with representation of fig discussion, but whitespace discussions have no place on this list... The standards being dictated by FIG are at odds with those adopted here for many years? So should we be asking them to change the standard to comply with already documented standards, or alternatively should we be bowing to their proposals and rewriting the core standards? So the discussion should be Do we accept that they are a legitimate standards authority? or simply ask them to indicate that they ARE at odds with the existing adopted standards? Lester, please stop arguing every point here. Especially really silly stuff like this. These are not even the same languages. The main core coding standards are all about C-specific things like freeing memory, zero-terminated strings, never using strncat, macro usage, preprocessor usage, internal naming, C-commenting, KR style stuff, testing, folding, and yes there is a single line about tabs vs. spaces which is the one thing you zeroed in on and could possibly apply to both C code and PHP code, but the fact is that the core coding standards have nothing to do with user-space PHP coding standards and were written specifically to apply to the PHP core code written in C. Personally I use the same editor settings to edit C/C++ as I do PHP, Javascript and the like. I have always worked that way and following the same rules on PHP files as C/C++ files just made perfect sense. Having used that style for many year prior to even using PHP. Now some third party is proposing that THEIR view of the world is the one everybody should follow? The core project has always been flexible on accepting different views of things? If that is about to change surely there should be some statement as to whether that view is about to change? PHP FIG is being pushed more and more as THE standard, but without any legitimacy? Certainly projects are changing coding styles to comply without any real debate on whether their 'rules' are generally acceptable? There is nothing wrong with what I view as the current standard being used by the core project and I see no reason to change from that ... there is certainly no 'alternative' standard documented by the core project? The call was whether there should be a representative on their 'team', but surely the debate should be about if it is the appropriate forum to decide standards that apply to the whole PHP infrastructure? i.e. does the standards being proposed there get endorsement from the core project? Does a representative from this project give that one 'official legitimacy' ? One gets the impression that it's all too late, so from the other side, should all of the core files be changed to follow the new de-facto standard? And YES I classify using different white space standards for different file formats as more of a problem! Writing files in one format which are then used to create files for a different format is a recipe for confusion? It's bad enough trying to get EOL right between OS's without adding 'what tab standard are you using' :( -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Core liason for PHP FIG
On 12/16/2012 03:20 PM, Lester Caine wrote: One gets the impression that it's all too late, so from the other side, should all of the core files be changed to follow the new de-facto standard? And YES I classify using different white space standards for different file formats as more of a problem! Writing files in one format which are then used to create files for a different format is a recipe for confusion? It's bad enough trying to get EOL right between OS's without adding 'what tab standard are you using' :( The core coding standards will not change regardless of what some outside group says, nor do I expect any other project to change their standards. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Core liason for PHP FIG
hi, What does that have to do with the initial question? It is getting really annoying to see you hi jack every single thread in this list with totally off topic and lengthy replies. It does not matter if what the questions raised are important or not, they are off topic. We do not, and do not want to, discuss CS or any other topics discussed, proposed or decided by the FIG group but how we can better cooperate and how it can be done. On Mon, Dec 17, 2012 at 12:20 AM, Lester Caine les...@lsces.co.uk wrote: nip standard are you using' :( -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Core liason for PHP FIG
On Sun, Dec 16, 2012 at 10:29 PM, Pierre Joye pierre@gmail.com wrote: hi, What does that have to do with the initial question? It is getting really annoying to see you hi jack every single thread in this list with totally off topic and lengthy replies. It does not matter if what the questions raised are important or not, they are off topic. We do not, and do not want to, discuss CS or any other topics discussed, proposed or decided by the FIG group but how we can better cooperate and how it can be done. On Mon, Dec 17, 2012 at 12:20 AM, Lester Caine les...@lsces.co.uk wrote: nip standard are you using' :( -- Pierre @pierrejoye Steering things back to the original topic, my objections to collaboration with FIG seem to be pretty much centered around their edictal approach to userland style guidelines and how our involvement could be construed as an endorsement of said style. If they would agree to make some modifications to this approach, I'd probably be able to withdraw my objection entirely. Lars, if you're open to that (keeping in mind that you don't speak for them of course), send me an email and let's see if we can brainstorm a solution off-list. =) --Kris
