Extra visual debt

[Ocramius]

This is just an attempt to fix the type-hinting mess inside the library. This is a BC break, as inheritance may be broken if the child classes do not respect the parent class signature.

Also, I suggest removing all the scanner stuff before merging.

[fhein]

@Ocramius: I think that the scanners would profit from a refactoring. If they will get replaced eventually then there is no need for that.

Is the scanner stuff going to get deprecated? Replaced by what? nikic/PHP-Parser?

Thanks for any hint. :)

[Ocramius]

Is the scanner stuff going to get deprecated? Replaced by what? nikic/PHP-Parser?

https://github.com/Roave/BetterReflection

[lisachenko]

@fhein @Ocramius It would be nice to drop all scanners from this library too for 4.0, similarly to annotations, because roave/better-reflection or goaop/parser-reflection or even nikic/php-parser can handle this work separately, whereas this library will solve only one task: provide an API for source code generation.

Will prepare a separate PR for dropping scanners after rebasing and merging this one.

[Ocramius]

after rebasing and merging this one.

Dropping the scanners is probably a better idea for now.

[lisachenko]

Dropping the scanners is probably a better idea for now.

Ok, let me check if they could be easily dropped..

[lisachenko]

Dropping the scanners is probably a better idea for now.

I've checked some dependencies and this is short summary:

• Whole Scanner namespace could be removed, there are only dependencies in Reflection namespace, eg. Zend\Code\Reflection\DocBlockReflection::reflect uses DocBlockScanner class, as well Zend\Code\Reflection\FileReflection::reflect uses CachingFileScanner. All remaining integration parts could be removed as they unused.
• Classes from the Reflection namespace adds some public API to the PHP internal classes, thus Reflection namespace could not be easily dropped if we want to support *Generator::fromReflection() methods that accept only Zend\Code\Reflection classes and use specific methods from reflection.
• If we decide to drop fromReflection() method from all generators or replace typehint in them with built-in PHP classes, then whole Scanner and Reflection namespace could be dropped, but it will be significant BC break as we remove all functionality that are not related directly to the code generation.

What is your vision about that?

I like the idea to drop both Scanner and Reflection namespaces from the code. Missing functionality will be covered by external reflection libraries. Make fromReflection methods accepts PHP's core classes instead of Zend's one, this will give quick way for integration via Reflection classes.

[Ocramius]

• Whole Scanner namespace could be removed, there are only dependencies in Reflection namespace, eg. Zend\Code\Reflection\DocBlockReflection::reflect uses DocBlockScanner class, as well Zend\Code\Reflection\FileReflection::reflect uses CachingFileScanner. All remaining integration parts could be removed as they unused.

Yeah, this stuff can be dropped. At this point, pointing to roave/better-reflection for most of the "brute-forcing the filesystem, looking for symbols"

• Classes from the Reflection namespace adds some public API to the PHP internal classes, thus Reflection namespace could not be easily dropped if we want to support *Generator::fromReflection() methods that accept only Zend\Code\Reflection classes and use specific methods from reflection.

Not sure about this one. I think the initial idea was that ext-reflection had huge potholes, and the library tried to fill them. I'd keep this for a separate issue, to figure out if the Zend\Code\Reflection namespace actually does anything more than ext-reflection these days. Considering that Zend\Code\Reflection is the entry point to all of the usages of this library (including the generators), I think that would make the migration path too painful at first.

• If we decide to drop fromReflection() method from all generators or replace typehint in them with built-in PHP classes, then whole Scanner and Reflection namespace could be dropped, but it will be significant BC break as we remove all functionality that are not related directly to the code generation.

The ::fromReflection() constructors are extremely useful to mimick API without rewriting all of it manually, so I'd probably keep them in place. Instead, I think that allowing core reflection classes as parameters would be a better solution here.

I like the idea to drop both Scanner and Reflection namespaces from the code.

Let's start with the Scanner only for now.

[lisachenko]

Moved to #155 to separate issue discussion.

[weierophinney]

This repository has been closed and moved to laminas/laminas-code; a new issue has been opened at https://github.com/laminas/laminas-code/issues/12.

[weierophinney]

This repository has been moved to laminas/laminas-code. If you feel that this patch is still relevant, please re-open against that repository, and reference this issue. To re-open, we suggest the following workflow:

• Squash all commits in your branch (git rebase -i origin/{branch})
• Make a note of all changed files (`git diff --name-only origin/{branch}...HEAD
• Run the laminas/laminas-migration tool on the code.
• Clone laminas/laminas-code to another directory.
• Copy the files from the second bullet point to the clone of laminas/laminas-code.
• In your clone of laminas/laminas-code, commit the files, push to your fork, and open the new PR. We will be providing tooling via laminas/laminas-migration soon to help automate the process.