Drop annotations support?

[Ocramius]

I just skimmed through the codebase of ZF2 and couldn't find scenarios where the "base" annotation parser of zend-code is used in it, except for zend-di. We could probably get rid of the entire Zend\Code\Annotation namespace.

While I realize that coming from me it sounds like I'm suggesting for people to just use doctrine/annotations, this part of the codebase really lies unused, and is a relatively complex layer that just proxies through to doctrine/annotations, in fact.

I propose deprecating it (probably 4.0) and dropping support for it in the subsequent major version. This allows us to also get rid of the zendframework/zend-eventmanager dependency inside zend-code.

[stof]

@Ocramius why waiting a major version to deprecate it ? A deprecation can happen in a minor version (deprecating is not a BC break when done properly. The BC break would be the removal)

[Ocramius]

@stof 3.0 is gonna happen real soon ( #29 ), and this sort of decision isn't something I can take on my own anyway.

[weierophinney]

@Ocramius I think we use Zend\Code\Annotation in zend-form as well; can you check?

In terms of deprecation, we could add the deprecation to the 3.0 release of zend-code, as far as I'm concerned.

Also, one question, what did you mean by this?

This allows us to also get rid of the zendframework/zend-eventmanager dependency inside ZF2.

That has never been proposed…

[Ocramius]

@weierophinney zendframework/zend-eventmanager is required only due to how the annotation manager works: removing annotation support means that no event manager is needed either

[Ocramius]

@Ocramius I think we use Zend\Code\Annotation in zend-form as well; can you check?

Yes, but by default it just uses doctrine annotations

[weierophinney]

The clarification is s/ZF2/zend-code/ in your original statement. :)

Regarding zend-form, we should make a note to drop support for Zend\Code\Annotation for the next major release of that component, which will make your suggestion possible.

[lisachenko]

Maybe we could start with making zendframework/zend-eventmanager optional dependency? And move it to the suggest section only for annotation, because event manager is used only for annotation parser and this is very rare case.

This will drop explicit zendframework/zend-eventmanager dependency. It could be easily fixed on project level via require.

[lisachenko]

@Ocramius @weierophinney what do you think about my previous question about making optional dependency with possible removing in the next major?

[Ocramius]

@lisachenko making the dependency optional is already a BC break, so I'd just go with a new major

[lisachenko]

making the dependency optional is already a BC break, so I'd just go with a new major

@Ocramius it's perfectly ok for me 👍

Also PHP strict types are welcome for new major ) So, my huge vote to make this library de facto standard for code generation

[Ocramius]

Yeah, the library is way sub-standard compared to most other components, but can be improved with some spit & polish

[lisachenko]

#123 is nice polisher, are you going to proceed PR yourself or maintainer is required?

[Ocramius]

@lisachenko I won't be able to continue on that for now, sorry.

[lisachenko]

Are there other maintainers? Maybe I will be able to spend some time on this library...

[Ocramius]

@lisachenko @zendframework/community-review-team is maintaining this. zend-code is relatively low maintenance, but we really do need to move forward with spring cleanups, so if you want to take over on that patch I can gladly help/review while commuting every day :-)

[lisachenko]

Unfortunately, @zendframework/community-review-team is private, so haven't idea how to ask members about possible changes. But your review and PR merging should be enough )

Let me check if I can help. I will propose list of todo and changes for 4.0 and link them with PR's

[Ocramius]

@lisachenko even just a patch removing annotations is sufficient for now - the other one can be rebased.

[weierophinney]

@Ocramius — We use the annotation support in the zend-server package, and thus each of its dependents (zend-json-server, zend-soap, zend-xmlrpc). Each of these needs some significant refactors at this time, though — but annotation support will still be required for any exposed methods with variant signatures. If there's a third-party package that provides that functionality, we can move to that; any suggestions would be quite welcome!

@lisachenko Team pages cannot be viewed publicly, even if the team is public. You can always mention the team in order to ping all members for review, however.

[lisachenko]

@weierophinney Maybe, switch for the next version to the doctrine/annotations library? It's already listed in require-dev section, thus installed during development process.

Also, I couldn't mention team, it's unavailable for me, even in my previous comment link is not bold.

[weierophinney]

@lisachenko D'oh! We use that with forms already, so of course I should know that one! Yeah, that would work fine, and we can use that in the other packages as well.

[lisachenko]

@weierophinney ok, so, doctrine/annotations should be ok. But not sure, should it be included as direct dependency, because main responsibility of this library is to generate code and provide API for that.
In my opinion, parsing of annotations should be outside of this library's scope, so no getters for annotations are required.

[Ocramius]

@Ocramius — We use the annotation support in the zend-server package, and thus each of its dependents (zend-json-server, zend-soap, zend-xmlrpc). Each of these needs some significant refactors at this time, though — but annotation support will still be required for any exposed methods with variant signatures. If there's a third-party package that provides that functionality, we can move to that; any suggestions would be quite welcome!

@weierophinney this would be in a major version anyway, so the affected packages would need to bump the dependency anyway.

I think I told this in 2013 or so btw: let's not come up with further different annotation syntaxes. Getting rid of this alternate parser/syntax is a good thing (TM)

[Ocramius]

Handled in #153