Hi All,

Disappointed to see that codeigniter is not listed in voting member group at PHP Framework Interoperability Group (fig-standards)?

See https://github.com/php-fig

Personally, I don’t like some of the “standards” they recommend.  I would hate to see CI as part of it.  It might give reason for me to fork CI and carry on my own work privately.

For example:

Code MUST use 4 spaces for indenting, not tabs.

I always use tabs.  Most standards recommend tabs, not spaces, for the simple reason that some people like a 2 space indent, others 4, some even 3 or 5.  If you set the tab stops on your editor, and if everyone uses tabs, then it will appear visually the way each person wants it individually.  I like a 2 space indent, and absolutely abhor 4 spaces, as the indenting gets out of control way too fast with that method.  2 is plenty for visual differentiation, especially when you have a high end editor or IDE that draws the graphical indent lines for you.

There are many examples from scanning over their standards that I simply would not adhere to, and several of their standards were “preached against” in both my classes at University and by former employers (I employ myself now.)

Sorry, it just seems to me that they have some people that just “don’t know any better” trying to create standards on how many different projects can become “interoperable” when some of them just weren’t meant to be, such as Cake and CI.  They weren’t designed to complement each other, they were designed to compete against one another.  Pick one, and stick with it.  Trying a mish-mash together just makes a mess.

This is something that is currently under discussion.

There are two kinds of standards that they are discussing about, and they haven’t quite figured out how to deal with that.

One is about framework interoperability. PSR-0 and PSR-1 fall in this category. These are important for the PHP community as a whole. You might have personal feelings about them, but these have to be set aside for the greater good of the community.

Imagine that CI would be PSR-0 and PSR-1 compliant. Then all of a sudden you find yourself not limited to the handful decent CI specific libraries that float around, but you can tap into the vast set of compliant libraries that will be available, and that are framework agnostic.

Also, this works at the framework component level. You could decide that you like the cache component from Zend more then the one supplied by CI, and you can simply swap.

The other set of standards have nothing to do with interoperability, but more with uniformity, educating the PHP public, trying to find a common ground for developing applications. PSR-2, the “coding standard” standard, falls in that category.

I can see why they feel this should be part of their job, if everyone uses the same set of standards, it would be a lot easier to hop from one piece of code to the next.

On the other hand, a lot of them fall in the category of “personal preference”. And it should be up to you whether or not you implement this standard. As it doesn’t impact interoperability, that is perfectly fine.

I think it’s a good idea if someone would represent CodeIgniter, the question is whether that should be someone from Ellislab or the Reactor team.

Given the fact that some of these standards impact architectural choices, it is my feeling it should be someone from Ellislab. But I don’t think anyone there is interested enough in the PHP community as a whole to join (but I might be wrong).

Thanks for reply in civil manner
I think this could be a good start for those who release code by the metric fuckton . Anyway personally i welcome, but there are few doubts that how 22 people can decide fundamental coding standards for a community of millions. Well I’m not against what the FIG is trying to do but i would love to see what other people think about it. I would suggest to be it more open and let’s decide community as whole.it’s a great concept, that it just needs to be more open to be better.

That’s why some of us try to get a discussion started about a more formal voting process going, a bit the way RFC’s work.

As you correctly said, you can’t have a handful of people decide in two weeks (the maximum time to cast a vote) how the rest of the community should work. Also, not all members are as professional as they should be. Deciding to vote against a new member “because I don’t like their code” is definately not the way to go.

The more people know about FIG, and the more people apply for membership, the wider the acceptance of any proposed standard is going to be.

They still have a long way to go, but if we don’t chip in, they will never get the size needed to make the difference…

WanWizard - 07 June 2012 11:48 AM

Imagine that CI would be PSR-0 and PSR-1 compliant. Then all of a sudden you find yourself not limited to the handful decent CI specific libraries that float around, but you can tap into the vast set of compliant libraries that will be available, and that are framework agnostic.

Also, this works at the framework component level. You could decide that you like the cache component from Zend more then the one supplied by CI, and you can simply swap.

That would take nearly a complete rewrite from the ground up of many of the frameworks out there. The reason people choose one over the other is because people think differently about how things should be accomplished.  Trying to bring it all together to be “hot swappable” so to speak defeats the purpose of the diversity.  You’ll find that CakePHP users will not want to compromise on how they do things to make some CI users happy, and CI users in general will not want to give up their ease of use to allow command line baking as CakePHP users demand.

The different frameworks were created to start with because so many people see a different way of doing things.  If you want to bring all the frame works together, then once they have all been homogenized, a new range of frameworks will crop up that are non-compliant to satisfy those who feel they were alienated by their homogenized framework.

Just my 2 cents.  I don’t mean to seem rude, but my honest professional opinion is that the “can’t we all just get along” ideal is unrealistic.

It would not mean a complete rewrite, but PSR-1 for CI would at least mean a different API, as class and method names will change. What happens inside the methods is not relevant to interoperability. PSR-0 would already allow the use of third party libraries following the standard, and that only requires a compatible autoloader.

To give an example, FuelPHP v2 is (going to be) PSR-0 and PSR-1 compliant. It differs from CakePHP like day and night. And both are completely different to how CI’s architecture is designed. And it would be nice that if you decide to standardize on Doctrine as your ORM of choice, that you can just dump it into your framework of choice, and it will work.

This is what the standard is about. It is not about how frameworks should work, it is about how you define the API and how classes are loaded, to make code interoperable at the class level.

For the same reason they are now discussing what you can call an extension to SPL (Standard PHP Library) to define a common interface for libraries. So if you have a class that implements an interface, you can swap the class by another that implements the same interface without impact to your application.

Once interfaces like this are defined, and people start building libraries based on these interfaces, you as a developer will no longer be limited to what is available inside the CI community, but you can also use libraries that someone has written for another framework.

seems Phil also in favor of PHP-FIG. checkout this http://philsturgeon.co.uk/blog/2012/05/composer-with-codeigniter

That blog post describes clearly the advantages I’ve been writing about.