Vendor prefix naming convention collides with de-facto standard annotations
mindplay-dk opened this issue · comments
The vendor prefix naming convention collides with de-facto standard annotations, namely @property-read and @property-write, which under this naming convention would consider property a vendor name.
Do we really need this alternative namespace approach? Isn't it enough we support PHP namespaces?
IMO, we have way to many options, syntaxes, conventions and meanings for the tag-name itself - we have the vendor- convention, we have vendor\Class PHP namespace syntax, and we have the specialization syntax with : as well.
It's too much, and it's unlikely any of it is ever going to catch on or get widely used - the vendor\Class convention is what people use now, and it doesn't get in the way.
If we must have this feature, how about using actual syntax, such as vendor., instead the vendor- convention, so we don't have to break from de-facto php-doc on this one?
On hindsight I think we should drop the section on vendor name spacing. If a codebase adopts this PSR it will automatically adopt the tag definitions in this PSR and such a note is almost obsolete and causes conflicts with existing tags and annotations