You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "Alex Medvedev (JIRA)" <ji...@apache.org> on 2015/03/18 13:08:38 UTC

[jira] [Created] (THRIFT-3046) Allow PSR4 class loading for generated classes (PHP)

Alex Medvedev created THRIFT-3046:
-------------------------------------

             Summary: Allow PSR4 class loading for generated classes (PHP)
                 Key: THRIFT-3046
                 URL: https://issues.apache.org/jira/browse/THRIFT-3046
             Project: Thrift
          Issue Type: New Feature
          Components: PHP - Compiler, PHP - Library
    Affects Versions: 0.9.2
            Reporter: Alex Medvedev


Nowadays thrift PHP library contains it's own class loader lib/php/lib/Thrift/ClassLoader/ThriftClassLoader.php for loading of generated classes. This loader is based on psr0 approach and combines it with some thrift specialties like locating all the structs and exceptions in Types.php file and all the service classes (processor, interface, rest handler, *_args and *_result) in single service file.

These points make thrift class loading not so flexible:
1. It is not possible to use advantages of psr4 autoloading. For example we cannot omit first part of class namespace inside procedure of translating namespace to file system paths. It can be useful when we are locating generated client classes in some vendor package inside the application.
2. This approach makes impossible to use all the power of Composer class loader (except the case when we providing preliminarily prepared classmap for the thrift classes) to load classes and forces to register ThriftClassLoader each time when we use generated classes.

The patch attached allows generation of all the PHP classes in separate files in case of 'psr4' option is provided. Such generated classes can be loaded with standard composer (or any other psr4-compatible) class loader.

Because of big amount of *_args and *_result classes thrift compiler with psr4-option generates significant amount of files. Nevertheless we can consider refactoring (omiting) of these classes in separate PR (may be we can implement java-style approach there).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)