PSR's adoption about prestashop HOT 5 CLOSED

Hi,

Thanks for your report but, we don’t accept issues on GitHub.
All issues have to be posted on our bug tracker : http://forge.prestashop.com or on our forum
So i close this issues, and please report your bug/feature on our bug tracker.

Regards

from prestashop.

@vAugagneur, could you please read the issues before closing them with the same message ?

Ok, you want to maintain your JIRA bugtracker, but then why did you open the Issue Tracker ? Obviously, this won't be the last issue that is going to be reported here. People are naturally going to make that.

At least, please let us use the Issue Tracker to discuss some feature improvements, like what @theUniC is proposing, which has been discussed on PrestaShop's forums a few times.

PrestaShop's forum is no longer the place to discuss that.

PSR & Composer would be a huge step for PrestaShop, so please don't be closed to discussion.

from prestashop.

Here are a few thoughts about integrating PSR into PrestaShop

PHP 5.2 support

PrestaShop wants to stay compatible with PHP 5.2, so it means no namespaces. I don't know what are the future directions, but this restriction lets few alternatives for clean namespacing.

We could use vendor prefix PrestaShop_, but this could break existing code.

Composer

How would we use Composer inside PrestaShop ?

PrestaShop is not a library, it is a "all-in-one" webapp. It almost can't run without a database, and its own "runtime".
This would be interesting to turn PrestaShop into an "e-commerce library", with features such as catalog, cart.. but this is a LOT of work, and a brand new direction for the software !

The other usage of Composer would be to manage third party libraries, like Smarty. This would make sense.

Autoload

PrestaShop doesn't have a conventional autoload mechanism, to manage the "override" system. I'm not an expert of PSR autoloading, but I think the fact that the class name doesn't correspond to the file name can cause problems, no ?

In general, the main problem is maintaining backward compatibilty and making sure third party modules still work. It's maybe time for difficult choices.

from prestashop.

@alexsegura Indeed if Prestashop wants to continue supporting PHP 5.2 leaves almost few possibilities. The only alternative to PHP 5.3 namespaces would be class prefixes like PEAR or Zend Framework 1.x. This is still compatible with the PSR-0, because the recommendation is both for namespaces and class prefixes. The counterpart is that these would possible lead to BC breaks. But are there many hostings still supporting PHP 5.2, in times that we are facing towards PHP 5.5 ... ?

Composer is not only for library projects. For example, Symfony2 exists as a base application and as a library, so that the base application requires the library. And as you noted, I think that Composer fits in Prestashop in order to handle vendor dependencies, like Smarty.

For the autoloading ... I do know about the weird autoloader of Prestashop. Sincerely, I think that Prestashop should refactor and rethink the override system into a more object oriented way by the use of design patterns to allow proper extension of the core. I think it's almost weird that an autoloader generates classes on-the-fly.

https://github.com/PrestaShop/PrestaShop/blob/master/classes/Autoload.php#L99

But Composer is still flexible enough for class loading. Mainly it supports PSR-0, but can generate classmaps given a directory (this combined with APC is the recommended setup for production environments) or include a set of files.

http://getcomposer.org/doc/04-schema.md#autoload

Christian.

from prestashop.

Very interesting Christian.

Namespaces

It's clear that namespaces are the only way to make sure existing third-party modules continue working.

Anyway, I'm afraid there is no way to get rid of the use statements.. For example, if we put the Product class in a namespace :

namespace PrestaShop\Catalog;
class Product {
    // ...  
}

To use it without breaking existing code, you would need to import the class :

use PrestaShop\Catalog\Product;

Is there a way for modules to continue working without declaring the use statements ? I haven't played much with PHP namespaces, but I'm afraid the use statement needs to be found in the file using the class, not from the outside.

It means existing modules would need to add the use statements. It could be possible to make a script that parses module files to find the classes used and add the statements.

Override / Autoload

IMHO the "override" system shouldn't exist.

PrestaShop's code respects the "open/close" principle in the wrong way : it is open to modification, and not extensible. Naïve inheritance is not the way to go, composition should be used with Adapter / Strategy pattern, and only for some clearly defined extension points.

BUT some modules may install their own overrides, or some custom shops may rely on overrides

Not sure it fits for all the classes, but to keep things simple while preserving existing code, any *Core class shouldn't be instanceable. The autoloader should always use the empty extended classes in the override folder.

from prestashop.