[proposal] Move to PSR-2 code style from Kohana code style #597
Comments
|
👍 Using anything other than PSR-2 is a PITA. |
|
By the way, this move should be done for the whole of the application, and it should be a quick one. |
|
If we are going to move to the PSR-2 standard for all of the modules (which I think is a must), it would have to be in their major version; 4.0. This is because all method names would have to be changed to camelCase which would completely change the API. However in the meantime, we could officially encourage people to use the PSR-2 standard when writing their application code (instead of promoting the Kohana style). |
|
As I've said in other places this has been discussed, I'm still concerned that switching old code to PSR-2 formatting will cause problems with merging bugfixes etc up from earlier to current releases - unless we drop support for everything but the most recent release. It will also make it much harder to trace code changes back through the history, which will make it more difficult to understand where code has come from when looking at refactoring/bugfixing/new features. But I accept that sticking with Kohana style is also problematic. Maybe we have to bite the bullet re whitespace, braces, etc. But I am 100% against ever renaming the existing classes and methods to PSR-2 naming conventions. It would place a huge burden on anyone with existing apps, and I think the majority would choose not to upgrade at that point. Using PRS-2 for new packages (like @lenton's module loader) is a good idea, and will allow a gradual migration based on features rather than formatting. |
|
👍 for 4.0.0 as it will introduce a non-BC change. |
Well, people don't have to update to 4.0.0. Obviously, though, the ~3.0 would need to get security and other patches, until it's put down forever and support for it stops. |
What's the point then? Basically nobody new is going to start using Kohana at this point, so if 4.0.0 becomes the point that it becomes too much hassle for the existing userbase to upgrade then the time spent renaming the methods in our own repos is wasted and we might as well close the project now. There's lots of good feature-based changes in the pipeline that will be worth a bit of upgrading for - kicking everyone out just so we can rename the whole API with no actual change seems crazy.
If there's a commit touching every single line of every single file between 3.0 and 4.0 then none of those patches can be merged up (or backported) without manual conflict resolution of every line. 4.0 basically becomes a hard fork of 3.0. Unless there's a big increase in the size of the team, that will result in either 3.0 or 4.0 being dropped sooner rather than later because it's too much hassle to support both. |
|
The point is to bring this code base into 2015. I personally wouldn't want to work with a non-PSR-2-compliant library unless I have to, so basically I just want to find out here whether there's an interest to achieve PSR-2-compliance or whether this library here's dead, more or less. |
|
I'm fully suggest with @localheinz. I have a really big project (over 100k business logic lines) on Kohana 3.2 and at previous week i made update from 3.2 to 3.3. New projects I will made with Zend2 (already have big one) and with Laravel or Yii2 for lightweight. Community should solve issues with standards to be modern framework at first, and only then other issues. |
|
@lenton , good point of view:thumbsup: |
|
@seyfer upgrading from 3.2 to 3.3 is comparatively simple, there were a few API changes and the filenaming convention switched to PSR0 (uppercase vs lowercase). Are you seriously saying you'd be OK spending the time to update your project to cope with every single core/module method being renamed to camelCase? And presuming your own code also uses Kohana-style naming conventions, you're happy to rename all of that too? I don't think many would. We've a few decent-size Kohana projects, and I really don't think I could justify the time to do that. I'm all for functional changes to come up to standards, but see no reason to change the code style if that means every single existing project has to be rewritten. We already support PHP5.5 (and 5.6, and HHVM) for 3.3 upwards - check the Travis builds. 3.3 and up can be installed quite happily with composer (it's default for 3.4), and work alongside any PSR0/4 autoloader with no problem. 3.4 also supports namespaces for your own code, and I think we could introduce them for core modules without too much problem if we provide end-users a script or namespaceless bridge to help with upgrading legacy projects. We may start introducing PSR2 naming conventions in some packages as part of implementing new interfaces (eg the open discussions about using PHP-FIG cache and log interfaces) - but that would be for functional reasons, to allow people to use external code easily. @localheinz I can't speak for anyone else, but IMHO Kohana is not dead for people that already use it, but isn't and won't be a good choice for new users/projects. We've been overtaken and left behind, and don't have the team size for it to be even slightly worth trying to catch up again. We'll never get there. If we accept that, then the focus has to be on modernising and bringing up to date only so far as we can bring existing users with us. Anything else is just wasting all our time writing code for people that will never, ever, use it. |
|
@acoulton upgrading of framework simple, but as I said - I have a big project. And also should update old modules (not mine) by fork them and update them and add to composer, because there is no maintainers. And don't forget about tests for business logic. And yes, all my own code in PSR style from beginning to the end. People, who already use Kohana have problems, new people prefer to start with other frameworks with at least Namespaces. |
With that attitude, they definitely won't start. I envision a prosperous future, as long as we make the necessary changes to turn Kohana back into the modern framework it once was. I'm sure you'd agree that converting our existing code base to the PSR-2 standard is the single most important change we could make for bringing Kohana back into the modern PHP era. So considering the importance of the change, I don't understand why you're arguing about a major release being backwards incompatible, that's what they're supposed to be.
There's not going to be a similar opportunity to the kohana/modules package again. If we don't change the modules to PSR-2 in the major release, then they are going to remain using the Kohana style indefinitely. Continuing to use our own framework-specific coding styling will be the death of Kohana.
The user upgrade process can be automated by a code sniffer or a regex search and replace. |
Good for you, but I think there's a huge amount of work to do before that's even vaguely likely and I don't see that there's anything like enough people available to do it. Not to mention whether the world actually needs Kohana back when there are so many good alternatives. What user need are you trying to serve? Every time one of these "ignore the impact on legacy projects" threads comes up I see a guy slowly trying to sand the square corners off his wheel, watching everyone disappear into the distance with their brand new round wheels. "If I just sand it hard enough, I can make my wheel better than theirs again", he thinks.
Seriously? Placement of whitespaces and method naming conventions are more important than (in no particular order) namespaces, single responsibilities, dropping global state and singletons, dependency inversion, proper test coverage? Things that would actually make a difference to what you can achieve with a kohana application?
a) there's a difference between "backwards incompatible" and "rewrite your application". b) end-users will have a threshold of tolerance for backwards incompatible upgrades - every big change you ask them to accept effectively reduces how much you can ask them to change for something else. In other words, moving to PSR2 in the short term means dropping other BC breaking changes that would have far more impact.
Partially, perhaps. But if you're using some third-party modules that haven't been changed? Or some of your own code? Or code that dynamically maps strings or whatever to class/method names? You're going to have a huge amount of manual work to do to be sure that it changed everything it was supposed to and nothing it wasn't. We lost a bunch of people at 3.3 when all they had to do was change the case of their filenames and/or implement a backwards-compatible autoloader... |
|
The reason I'm a big advocate of converting to PSR-2 is I think we should all be aiming to improve Kohana's quality to the standard set out by the Ohanzee project. When Kohana is good/similar enough, Ohanzee could merged back into Kohana and we can join our long lost developer @shadowhand. It would be great to get to a point where we are focusing all our efforts on the same project while still having a community to back us. And by that point, Kohana would be considered a modern framework once more. What do you say? |
|
First of all, I don't intend to start an argument here, I've only had a look at the code as I might work on an existing application that has been built with Kohana, so I figured it would make sense to have a look at the framework already. The points I'm raising are made while being unaware of any discussions and decisions that have been made in the past for and/or against adopting certain standards, so I'm a total Kohana noob, if you will.
If there were API changes from
Not sure, but maybe the reason lies in failing to embrace more up-to-date standards? Happy to help making some changes! |
|
@lenton I just don't see a need for Kohana as an all-in-one framework any more, other than to support existing projects (and existing teams that would prefer to stick with something they know). From what @shadowhand has said before, I'm not sure he does either. Individual Ohanzee components together with other third-party packages, yes - but that's not really Kohana any more. If you're not interested in upgrade path for existing people, then why not just start working on Ohanzee components and potentially some wiring/bootstrapping/skeleton app for them?
Thanks, yes - we do know that. Kohana's versioning strategy long predates me and was decided before semver was so universally adopted. Kohana 3.0 was a total from-scratch rewrite of Kohana 2.0, based on both learnings from the older versions and changing standards/common practice. Upgrading from 2.x to 3.0 basically meant rewriting your whole application, and lots of people didn't. So 2.x and 3.x were supported together for a while, and for a short time both got new features. That meant that the second-level version number was used for major (breaking) versions, the third-level for minor versions and the lowest for occasional hotfixes/patches. Kohana version numbers are sort-of UNIVERSE.MAJOR.MINOR.PATCH. Kohana's not the only project to have done that. Symfony 2 for example also completely rewrote the framework between 1.x and 2.x, and then introduced breaking changes in early 2.x releases. They have now I think adopted a formal semver strategy for the future. That muddiness over versioning is one of the reasons I think a "rewrite-your-whole-application" PSR-2 etc version of Kohana should actually just be 1.0 of a whole new project. If 4.0 means massive breaking change, we're stuck using 3.4/3.5/3.x instead of semver for smaller breaking change for people that don't want to invest in the full upgrade.
I'm not disputing that - through a mix of sticking to the preferences of contributors at the time when it was far from clear that some of the standards would become so established so fast, but more because of a lack of contributions and a relatively small pool of users compared to frameworks that have made the leap. Instead of trying to fix Kohana, people who weren't happy with it used what they'd learned (positive and negative) here and moved away to other projects - Fuel, Laravel, etc. Partly that was to have the freedom to start from a clean slate rather than be handcuffed by the need to provide an upgrade path. I'm not criticising that, by the way. That's exactly what Kohana did from 2.0 to 3.0, and indeed when it split away from CodeIgniter in the very early days. I'm just saying that I think we're now so far behind and so small that it's unlikely we could catch up again, and I think to try would be a colossal waste of all our effort given that there are already plenty of good choices out there for new projects. I just don't see the need to compete with them for the sake of it, and I don't think we have anything much unique that hasn't already been taken and reused or improved by others. |
|
@acoulton Conservatism is against progress. If you want build something better, you should brake old and learn new. |
|
@localheinz thanks for suggesting to help us. We need more hands, and it seems that you are already a Zend contributor, which is great. Once you get along with the framework, and you start requesting great pulls, I hope you might be eventually considered for joining the team, if you feel like so. @seyfer do you realize what you just wrote? and are you sure you're saying this to @acoulton? Could we please show some restraint and just comment on the subject without superiority feelings and inclination to mentor? |
|
@seyfer I don't fear change, and I have no problem learning new things. Perhaps if you had been around longer you'd see I've already done a bunch to modernise, I'm in favour of namespaces, PSR1&2 in entirely new packages, using existing and well-specified third-party cache interfaces, adopting PSR3 logger interface, inverting dependencies and a whole bunch of other breaking changes that will improve the framework and make it more flexible for end-users. But renaming every existing method just for the sake of it? I really don't see that end users will feel the benefit justifies the effort of upgrading. Either they won't upgrade past that point, or they'll realise that for the same effort they could migrate elsewhere. I think it's conservative to insist on modernising kohana at any cost, rather than accepting that a) frameworks are dead and b) if you really want a modern framework for a greenfield project, or are willing to spend a huge amount of time migrating a legacy application there are plenty of projects that have already solved many of the problems we're talking about and are light years ahead of us and still moving forward. Wouldn't it be better to embrace change and use one of them? I really don't care about people leaving (or never adopting) Kohana. I'm not scared of a world where Kohana is a wikipedia entry and everyone has moved on to something better. I care about people in the real world, who are already using Kohana, can't justify investment in rewriting for the sake of it, and need to continue to maintain and develop their applications. For the next few major versions at least, we need to focus on making sure Kohana doesn't get in the way of adopting modern coding practices, and provide an upgrade path with a clear cost/benefit justification for breaking changes. |
|
I've just realised that not all methods have to be changed, a lot of Kohana's existing method names are only one word long. Now that transparent extension is being removed from 4.0 we can easily turn the original methods into deprecated aliases without worrying about extended logic not being called (as explained to me here). We can keep the methods deprecated for the whole of version 4.x if you like, that would solve @acoulton's worry of users not bothering to upgrade. It would also give us the opportunity to split up methods into getters and setters as well as other methods with multiple responsibilities. |
I will introduce my proposal with quote
It's quote from Issue of one Kohana module which follow Kohana code style.
So I decide to make contribution and found, that it's hard to me to read and edit (with IDE) code with no usual PSR-2 formatting. I'm discuss it with module owner and there is my proposal for Kohana community.
Let's move to PSR-2 standard for braces, spaces and etc formatting.
The text was updated successfully, but these errors were encountered: