Core liason for PHP FIG View as Markdown

Hi Lars,

Thanks for your detailed response. My thoughts inline below....

--Kris

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.craig@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.

hi Lars,

Hi Pierre,

Am 16.12.2012 um 13:08 schrieb Pierre Joye pierre.php@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

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...

Anthony

Pierre Joye wrote:

On Sun, Dec 16, 2012 at 3:26 PM, Lester Cainelester@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=**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<;
http://rainbowdigitalmedia.co.uk

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