Edit:
Here’s one example, you can define your routes in symfony using comments. Not only that, but it’s actually the officially recommended way of doing things. Absolute madness.
Edit:
Here’s one example, you can define your routes in symfony using comments. Not only that, but it’s actually the officially recommended way of doing things. Absolute madness.
Smuggling pragmas in comment has a long and rich history. It’s literally the reason why json does not support comments.
> Reading about JSDoc gives me the same uneasy feeling, even if it’s not quite the same thing.
It’s not just “not quite the same thing”, it’s entirely unrelated in every way and shape. JSDoc does not affect the runtime behaviour of its code, or how that code interacts with other systems.
At the moment. You’ve literally just said yourself that there is a long history of smuggling code into comments. A few years down the line I don’t want to suddenly have the feature added and then have to be on the look out when I’m debugging a codebase for secret code in comments.
From the page you linked:
> Routes can be configured in YAML, XML, PHP or using attributes. All formats provide the same features and performance, so choose your favorite. Symfony recommends attributes because it's convenient to put the route and controller in the same place.
Attributes are not comments, they are an official structured way of handling metadata.
[1] https://www.php.net/manual/en/language.attributes.overview.p...
In Java the keywords "public" and "private" use the same starting symbol too, what's your point? Attributes start with "#[", comments with "//" or "#". That's clear enough.
> it’s greyed out in the text editor like a comment
A language isn't responsible for a specific text editor's syntax highlighting.
It’s even greyed out like a comment in the official symfony documentation.
Docblock comments can also be inspected with reflection [3] but have a much looser syntax, so it was up to you to parse them. Where as you can create a new instance of an attribute directly from the reflection object [4]
In your example Symfony uses it to build up the list of HTTP routes by looking through all your controllers for #[Route] attributes. Generally that's done once and then cached, at least in production.
Personally I try to avoid using them, but they're definitely not comments. More like metadata you can attach to classes/methods/properties/parameters then use however you want.
[1]: https://www.php.net/manual/en/language.attributes.syntax.php
[2]: https://www.php.net/manual/en/reflectionclass.getattributes....
[3]: https://www.php.net/manual/en/reflectionclass.getdoccomment....
[4]: https://www.php.net/manual/en/reflectionattribute.newinstanc...
So comments that are code then.
Everyone can sit around going “This is not a pipe it’s a photo of a pipe or my perception of a photo of a pipe”. But if you did not have a sentence above your photo saying “This is not a pipe” or an arts teacher to tell you “this is not a pipe” and there was just a picture of a pipe on the page and someone pointed at it and said “can you tell me what that is?” You would say “why of course, it’s a pipe”. And then all of a sudden it started spouting water out of the end (let’s assume it was a GIF) then you can say “oh it looks like a pipe but it’s actually a water pistol masquerading as a pipe”. The fact that as a dev you have to constantly be on the look out for water pistols masquerading as pipes rather than having a clear distinction between pipes and water pistols is just a piss poor and easily avoidable design decision.
JSDoc is like 20 years old and not part of the javascript langage, it’s just a way of formatting some comments such that they’re programmatically process able.
What you're thinking of in PHP is not a comment. It's called an Attribute, is built into PHP itself, and while it does use a comment-syntax, it's the old style that is largely unused today ("#" at the start of a line). https://www.php.net/manual/en/language.attributes.overview.p...
JSDoc isn't similar at all, unless you build a compiler that does different things based on your JSDocs.
> Reading about JSDoc gives me the same uneasy feeling, even if it’s not quite the same thing
The key difference with TypeScript is that even "real" TypeScript types never ever affect runtime behavior, they are purely descriptive. This is an explicit goal of the project (and they've had to make some compromises in other areas to uphold it), so I don't see it ever changing