[PHP-DEV] Core liason for PHP FIG

[Lars Strojny]

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

Re: [PHP-DEV] Core liason for PHP FIG

[Kris Craig]

On Sun, Dec 16, 2012 at 1:02 AM, Lars Strojny  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

[Lars Strojny]

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 :

> 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

[Pierre Joye]

hi Lars,

On Sun, Dec 16, 2012 at 10:02 AM, Lars Strojny  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

[Lars Strojny]

Hi Pierre,

Am 16.12.2012 um 13:08 schrieb Pierre Joye :

> 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] DateTime improvement

[Derick Rethans]

On Tue, 11 Dec 2012, Derick Rethans wrote:

> On Mon, 10 Dec 2012, Herman Radtke wrote:
> 
> > Another option is to make an ImmutableDateTime class. The DateTime
> > class could actually be changed to inherit the ImmutableDateTime
> > class. The only extensions on the DateTime class would be the mutable
> > methods.
> 
> I'm not really against that, but we do need to use the Date namespace - 
> so DateTimeImmutable. It might be trickier to do than it sounds 
> though...

I've started hacking on this - with some luck I'm done before PHP 5.5 
beta1.

cheers,
Derick

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] DateTime improvement

[Lars Strojny]

This is so cool, thanks Derick! If you need help with testing or anything else, 
let me know.

Am 16.12.2012 um 13:21 schrieb Derick Rethans :

> On Tue, 11 Dec 2012, Derick Rethans wrote:
> 
>> On Mon, 10 Dec 2012, Herman Radtke wrote:
>> 
>>> Another option is to make an ImmutableDateTime class. The DateTime
>>> class could actually be changed to inherit the ImmutableDateTime
>>> class. The only extensions on the DateTime class would be the mutable
>>> methods.
>> 
>> I'm not really against that, but we do need to use the Date namespace - 
>> so DateTimeImmutable. It might be trickier to do than it sounds 
>> though...
> 
> I've started hacking on this - with some luck I'm done before PHP 5.5 
> beta1.
> 
> cheers,
> Derick
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] DateTime improvement

[Lester Caine]

I'm not really against that, but we do need to use the Date namespace -
>>so DateTimeImmutable. It might be trickier to do than it sounds
>>though...

I've started hacking on this - with some luck I'm done before PHP 5.5
beta1.


Am I missing something here?
Isn't this just making the object content read only?
Haven't we been having a separate discussion on that?

On the whole I'm only using DateTime objects when I need to display the content 
in a different timezone, so the timezone needs to be changeable, but the base 
date is read only. Alternatively I'm building a calendar so need 'all the days 
for month x' as an array, and then use those dates to generate the database 
query. If it's a 'local' calendar then there will be a time offset incorporated 
as well.


In Firebird, the dates are stored as a numeric value, with the whole part the 
number of days, and the fraction the time of day. Two 32bit values. When doing 
comparisons there is no point converting to a DateTime object, one converts FROM 
the DateTime to parameter suitable for the database, and leave the database to 
do the filtering.


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

[Lester Caine]

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

[Peter Lind]

You realize that this is not the list of PHP FIG, right?

On 16 December 2012 15:26, Lester Caine  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
>



-- 

WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15


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

hi Lars,

On Sun, Dec 16, 2012 at 1:20 PM, Lars Strojny  wrote:
> Hi Pierre,
>
> Am 16.12.2012 um 13:08 schrieb Pierre Joye :
>
>> 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

[Pierre Joye]

Lars,

On Sun, Dec 16, 2012 at 3:26 PM, Lester Caine  wrote:

>

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] DateTime improvement

[Никита]

I have actually started too, but I made it w/o inheritance from DateTime,  
and I made many of inline functions to avoid code repetition, so I don't  
know how good is it. The code on my work computer, so I can show it  
tomorrow.


Derick Rethans  писал(а) в своём письме Sun, 16 Dec 2012  
16:21:47 +0400:



On Tue, 11 Dec 2012, Derick Rethans wrote:


On Mon, 10 Dec 2012, Herman Radtke wrote:

> Another option is to make an ImmutableDateTime class. The DateTime
> class could actually be changed to inherit the ImmutableDateTime
> class. The only extensions on the DateTime class would be the mutable
> methods.

I'm not really against that, but we do need to use the Date namespace -
so DateTimeImmutable. It might be trickier to do than it sounds
though...


I've started hacking on this - with some luck I'm done before PHP 5.5
beta1.

cheers,
Derick


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Core liason for PHP FIG

[Lester Caine]

Pierre Joye wrote:

On Sun, Dec 16, 2012 at 3:26 PM, Lester Caine  wrote:


>

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

[Paul Dragoonis]

On Sun, Dec 16, 2012 at 7:46 PM, Lester Caine  wrote:

> Pierre Joye wrote:
>
>> On Sun, Dec 16, 2012 at 3:26 PM, Lester Caine  wrote:
>> 
>>
>>> >
>>>
>> 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
> 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]

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
On Dec 16, 2012 2:49 PM, "Paul Dragoonis"  wrote:

> On Sun, Dec 16, 2012 at 7:46 PM, Lester Caine  wrote:
>
> > Pierre Joye wrote:
> >
> >> On Sun, Dec 16, 2012 at 3:26 PM, Lester Caine
>  wrote:
> >> 
> >>
> >>> >
> >>>
> >> 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>
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>

Re: [PHP-DEV] Core liason for PHP FIG

[Lester Caine]

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

[Lester Caine]

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

[Rasmus Lerdorf]

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, K&R 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] DateTime improvement

[Derick Rethans]

On Sun, 16 Dec 2012, Lester Caine wrote:

> > > I'm not really against that, but we do need to use the Date namespace -
> > > >>so DateTimeImmutable. It might be trickier to do than it sounds
> > > >>though...
> > > 
> > > I've started hacking on this - with some luck I'm done before PHP 5.5
> > > beta1.
> 
> Am I missing something here?
> Isn't this just making the object content read only?

Sortof. But as that is how things work, making an immutable variant 
isn't that easy.

> Haven't we been having a separate discussion on that?
> 
> On the whole I'm only using DateTime objects when I need to display the
> content in a different timezone, so the timezone needs to be changeable, but
> the base date is read only. Alternatively I'm building a calendar so need 'all
> the days for month x' as an array, and then use those dates to generate the
> database query. If it's a 'local' calendar then there will be a time offset
> incorporated as well.

Al the methods will *still* return the modified DateTime object - it's 
just that the one that you *call* f.e. ->modify() on won't change 
anymore.

cheers,
Derick

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] DateTime improvement

[Stas Malyshev]

Hi!

> Al the methods will *still* return the modified DateTime object - it's 
> just that the one that you *call* f.e. ->modify() on won't change 
> anymore.

Doesn't it mean you can just call clone() on it in modifier methods
before doing anything else?
-- 
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] DateTime improvement

[Derick Rethans]

On Sun, 16 Dec 2012, Stas Malyshev wrote:

> > Al the methods will *still* return the modified DateTime object - 
> > it's just that the one that you *call* f.e. ->modify() on won't 
> > change anymore.
> 
> Doesn't it mean you can just call clone() on it in modifier methods 
> before doing anything else?

Yeah, I think so. I tried that but I got some errors. It's something for 
me to sort out. So far, I've just created all the helper methods etc. 
clone() however is not a method, but a language construct... so it's not 
that trivial.

cheers,
Derick

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Core liason for PHP FIG

[Kris Craig]

Hi Lars,

Thanks for your detailed response.  My thoughts inline below

--Kris


On Sun, Dec 16, 2012 at 3:42 AM, Lars Strojny  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 :
>
> > 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

[Lester Caine]

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, K&R 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

[Rasmus Lerdorf]

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

[Pierre Joye]

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  wrote:

> 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

[Kris Craig]

On Sun, Dec 16, 2012 at 10:29 PM, Pierre Joye  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  wrote:
> 
> > 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