Drop PhpFunction or add PhpFile

[gossi]

The question is how much is PhpFunction used at all? Basically, this library assumes, every code follows PSR-4 (1 file = 1 class/interface/trait). The only use case for functions would be to expect a function library anywhere, which would either require a PhpFile class, which itself would be capable of retrieving all classes, traits, interfaces, functions and constants from a file (as such no real php code block from such files) or drop the PhpFunction class, which is more likely to happen.

[RaoulSchaffranek]

The question is a lot about how opinionated the code-generator wants to be. PSR-4 is surely a good indicator for code-quality, at very least it shows that the author is aware of coding-standards and cares about maintainability. This, however, does not mean that libraries which do not comply with PSR care less about these challenges. In fact PSR does not end in itself, but it should be re-considered on per-project-basis. One driving question should be: Does it serve the API of the library to use PSR? This question cannot be answered in general and that's why i hope, that you do not give up on PhpFunction. There are always legitimate use-cases to build functional APIs and these do not benefit from PSR-4 too much. There are at least two hurdles, which immediately come to my mind: PHP does not have functional interfaces and it does not have autoloading for functions (there is a proposal which addresses the latter one). Also, fp libraries tend to compose from many small functions and splitting them over too many files would not contribute to maintainability of the code-basis. This is to say, deprecating PhpFunction would rule out valid use-cases.

Independent of the solution that you will choose, you made a great library and deserve all my gratitude.

[gossi]

I absolutely agree with you, however doesn't address the question here.

It must be seen from the perspective of code-generation. Structured code (classes, interfaces, trait) it's only about dumping code, in which order is irrelevant. In regards to procedural code, the order is highly important! For a class I can add methods as much as I want, sort them alphabetically and put the code into a file and it will work, not for procedural code.

I'm wondering what an API might look like to support this and if so it's worth to develop it. The model data for procedural code would either be a token stream or something like AST and then passed to the writer, which generates the code (php parser is already capable of doing that). PhpFunction would be the only model that can be used in that case (I mostly think of it as anonymous functions, e.g. for sth like silex code). However, you are unlikely to generate that kind of code from some kind of model (whatever it might look like), you will write if from hand and if you do, you probably have your pieces (in some form of templates) ready which you puzzle together.

I rather don't see the use case to provide APIs for generating procedural code, though my thoughts aren't finished on this.

[gossi]

I will mark them @deprecated in v0.6 with a message that points here and a call to action to join this discussion

[BlacKCaT27]

To add to the discussion, personally I don't think it should be up to the library to expect/enforce any sort of standard of the input code. Ideally, imo, there would be a PhpFile class which can just read in a file, regardless of the structure, and (assuming it's a valid, compilable PHP file), give back an object which describes its contents. It would be great to be able to point the tool at, say, a PHP CLI script which has global functions, code in global scope, and nothing else, and still be able to describe the contents to some extent. The global code may be tricky to implement unless you just take a naive approach and capture it all as a string and let the caller handle modifications, but it's still more functionality than exists currently, so it could be enhanced later.

In terms of keeping the code ordered properly, it would be easy enough I would imagine to track line numbers along with the code as it's being read in. And if global scope code is too tricky to handle in such a way, maybe just exclude that (or keep it in a string blob that the caller has to deal with and say 'good luck').

[gossi]

The thing you are talking about is a parser, that has an AST, that you want to modify and write it out again. Since php code generator is about generating structured code, it would then intersect the AST at functions and would return an appropriate model here. That's not of a good story here. Couldn't see any benefit in this.