Are we there yet? I want to go PHP 5.4.... Are we there yet?
Closed this issue · 9 comments
I am sure we all know being irritating to our parents, repeatedly asking "are we there yet" when on long road trips, does this ring a bell? Some of us have already experienced this from the other end of the stick or will soon be. Myself and @alganet as far as I know, are not close to that so allow me to experience the child within as you will be hearing me say this frequently:
Are we there yet?
Since we've recently been prive to a release of 5.5.alpha1 is this a good enough excuse to bump the minimum requirement already? If you think it's too early still I have only one thing to say: with puppydog face...
But what about generators?
We can't exactly go skip a version PHP or can we? ...and I can't start irritating you with...
Are we there yet?
...for wanting to use yield and send and... anyway...
Are we there yet?
Would it be allright... is it acceptable... would anyone complain profusely or go tell the parents if I do? =)
Are we there yet?
I actually have a legitimate reason as argument, premise, good excuse to justify the move. One of the big gripes we had, amongst others, with implementing #28 was the fact that PHP had no support for status codes and while I have been thinking, even implemented some, alternative approaches to the array collection with code to reason mappings, as you may know PHP 5.4 came with support for:
Need I say more?I think the topic is well documented already. Now it's true we could polyfill backward compatibility but eeeuuww and what about array short syntax we can't exactly stub that compatible. The sooner we're done with 5.4 the sooner we can move to 5.5 \o/ so one more time:
Are we there yet, already?
I like the idea of moving to PHP 5.4 and 5.5. Many users still use 5.3 though, and it's still supported by Zend and umconfortably present in default setups like Ubuntu 12.04 LTS. I believe we should polish up the current releases (no new features, just making what's there more stable and documented) and release the first and last 5.3 stable release to honor our current 5.3 users!
Generators will make our pandas umprecedentaly awesome!
BTW I'm trying to migrate Rest to PSR-2 and complete legacy tests migration. Anyone willing to help this week?
I can help, only looking for work inbetween.
Do we really have to do full PSR-2? =/
I started writing the code conventions if I recall where did I go with that?...
I personally don't like PSR-2, and even though adopting it isn't a sign of quality, users tend to interpret adoption of PSRs as such.
During the PSR-2fication I've found that most of our code (except for the 80 column limit and brances on control structures) is already OK.
I've also added docblocks to the code I've fixed, which is another popular "sign of quality" (even Ohloh considers that when crawling projects).
We still need our own conventions for naming, coupling, dependency injection and so on =)
Afaik the spec allows for 120 chars soft limit
There are several other items that are optional so you can still claim PSR-2 with exclusions
I really really really don't want begin/end for one line statements it's going against PHP design and what we stand for arguably. It wastes so much useless space =(
Wheres that post...
Found it https://github.com/Respect/project-info/wiki/Coding-Standards
It still needs a little work it seems.
I agree on letting the optional PSR-2 items out. I'm not sure about the 80/120 column limit, we need to see how the tools for checking that behave. In Zend, they had a hard and soft limit but the PHP CodeSniffer printed warnings when you break the hard limit. I should have tested that for PSR-2 =(
Sorry man that wiki page I found was your coding standard write-up
This is what I was doing.
Respect Syntax Convention (RSC)
from PSR-2
There MUST NOT be a hard limit on line length; the soft limit MUST be 120 characters; lines SHOULD be 80 characters or less.
The tools, both of them, were still very dodgy when I last looked at them and we will likely need to work on them to get it fixed. We might as well customise it to our RSC then where needed, what do you think?
I am closing this, although I am always eager to move forward into version requirements I would not likely do so just for the sake of it.
If we ever need to update the version, we should do so in that occasion.