Closed theofidry closed 5 years ago
another use case: mocking the class. Most mocking libraries rely on inheritance as mocking final classes otherwise requires complex things:
Case where there is only one class and making it final would require an interface
For clarity, lack of interface doesn't mean that the class cannot be final
. This argument looks the same as inability to proxy/mock the class.
None of these arguments are valid. You are trying to work around a platform, namely PHP, limitation. A class is final
if it is not meant to be extended, period. All other use cases should be added to PHP itself and not to documentation.
@Fleshgrinder following your logic, we would completely remove remove all phpdoc block, since it's a limitation of dynamic languages.
No, that is a deliberate design choice of the language and the annotations are meant to extend upon this. The disability to mock final classes is not such a choice, it is an overlooked feature.
I fail to see the problem. Even if the feature is integrated in the next minor release, it won't be usable for all the existing code, whereas supporting it via an annotation is easy.
The problem is that this standard recommendation (which will possibly never come) is the basis for all PHPDoc parsers, hence, it should be a minimal set of functionality that commonly adds value to all of them. It is meant to establish a baseline. This feature request should go to your favorite IDE vendor or documentation tool and not here.
The problem is that this standard recommendation (which will possibly never come) is the basis for all PHPDoc parsers
Yes, this is precisely why I'm making this issue here and not in phpdoc. Unless it's here, any php parser or IDE will be reluctant to integrate that feature which has legitimate use cases. As I said even if the requested feature land in PHP now, it will take years before the @final
tag would be completely useless. So IMO, it's reasonable to officialise this one (as it already exists in phpdocumentor) which could be valuable for a couple of years at least.
But we may simply have different views on it, that's fine, let's let the other speak as well and provide a bit more input :)
I've seen this tag occasionally mentioned in the wild, but I've never been keen on it, since, historically speaking, whenever a tag exists because the language didn't have the syntax, and then the language adds the syntax, then the code counts and the tags are redundant/ignored (e.g. @access
).
Ping @ondrejmirtes @muglug @neuro159 @mindplay-dk @GaryJones @mvriel @jaapio for opinions.
I understand why this is requested. But I don't think it should be part of the current psr. I think it could be part of a future psr. But I think we should focus first to standardis the widely used tags before introducing new tags. Especially because this new tag only will make sense when all tools have support for it. I have seen more usecases for @internal
so could that be a replacement of this tag?
+1 to @jaapio )
Looks like a no-go.
It would be nice if the
@final
was included as well. Whilst it's preferable to actually mark the class asfinal
instead of that tag, it is not always doable:final
would be a BC break, it could help to show the intent of making it final in future versions (see https://github.com/symfony/symfony/pull/20493 for example)@final
would convey the intent that if you were to need to extend that class, you should refactor and introduce an interface to implement the interface instead of extending the base class (which you can now mark asfinal
)final
classes are not supported. There is a discussion to maybe support it in a specific scenario (when the class implements only 1 interface or extend 1 class without implementing any interface), it won't cover all cases. In which case you either give up on using the proxy manager and keepfinal
, or you removefinal
in favour of@final
to use the proxy manager