Remove code scanners to improve library maintainability

[weierophinney]

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.

---

Originally posted by @Ocramius at zendframework/zend-code#123

[weierophinney]

@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. :)

---

Originally posted by @fhein at zendframework/zend-code#123 (comment)

[weierophinney]

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

https://github.com/Roave/BetterReflection

---

Originally posted by @Ocramius at zendframework/zend-code#123 (comment)

[weierophinney]

@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.

---

Originally posted by @lisachenko at zendframework/zend-code#123 (comment)

[weierophinney]

after rebasing and merging this one.

Dropping the scanners is probably a better idea for now.

---

Originally posted by @Ocramius at zendframework/zend-code#123 (comment)

[weierophinney]

Dropping the scanners is probably a better idea for now.

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

---

Originally posted by @lisachenko at zendframework/zend-code#123 (comment)

[weierophinney]

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.

---

Originally posted by @lisachenko at zendframework/zend-code#123 (comment)

[weierophinney]

• 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.

---

Originally posted by @Ocramius at zendframework/zend-code#123 (comment)

[weierophinney]

Moved to #155 to separate issue discussion.

---

Originally posted by @lisachenko at zendframework/zend-code#123 (comment)

[Ocramius]

Closing here: most of the scanner is gone in #58, while #45 is tracking most of the work to be done to improve the library at type level.