[
https://issues.apache.org/jira/browse/THRIFT-3046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Medvedev updated THRIFT-3046:
----------------------------------
Attachment: php-compiler-psr4-option.patch
> 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
> Attachments: php-compiler-psr4-option.patch
>
>
> 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)
