4 ms·

> Stuff that's in comments SHOULD NOT AFFECT RUNNING CODE. To clarify, comments never affect running code in PHP, ever. What's often done however is that tool

> Stuff that's in comments SHOULD NOT AFFECT RUNNING CODE. To clarify, comments never affect running code in PHP, ever. What's often done however is that tools like ORMs, or web frameworks offer a 'compile' step that parses these annotations (just like it's common in Java) and dumps a PHP file that maps things in the annotations into actual PHP code. For example, you can use it in Symfony to wire routes to handling functions in controller classes; or in Doctrine to help the mapper wire Entity classes to database tables. If you don't like the idea of preprocessing annotations, you can totally not use them and configure everything using external YAML/XML files.

elric 6y ago
Yeah I worded that poorly, but once I went full on caps I decided to leave it, ahem :/. I get the idea of a compile step, and that's totally fine. But these annotations are commented out. It's very icky to be using them for anything other than documentation -- which is what comments are for, after all. Java's annotations are a bit different. Sure, the compiler does things with them -- the runtime does, too --, but they're syntactically part of the language. In PHP, they're kinda of not. Not yet, anyway.
- slifin 6y ago
  Is a heftier compile step totally fine? The biggest difference between PHP and Java in my mind is that you start Java and pay the compile cost on server start, in PHP you pay the compile cost on every request, frameworks and language features increasingly hide this future cost in caches but caches are one of the two hardest things in computing and often act like pushing things under the carpet, why optimise the compile? It's under the carpet As we move closer and closer to Java's model, we get further and further away from that quick PHP feedback loop of, make a change press f5 see the changes immediately and quickly Which puts us further and further away from the kind of ideals that Bret Victor mentioned in his very good talk inventing on principle: https://youtu.be/PUv66718DII https://youtu.be/PUv66718DII which to quote: "Creators need an immediate connection to what they're creating." Inevitably this is coming and is already here but we should recognise what we've lost
  - agustif 6y ago
    Meanwhile with something like NextJS/TypeScript/React you can just enjoy instant reloads without ever caring about F5 again The more languages the better IMHO though
    - purerandomness 6y ago
      Did you just deliberately redefine 'reload' just to incite a flamewar, or do you really not know what's different in your example?
- bkanber 6y ago
  To be fair, I've been working in PHP for nearly 20 years and I've been able to avoid annotations almost entirely, except for that one time I used Doctrine and then threw it in the trash.
sfteus 6y ago
It absolutely shouldn't, but it _can_: https://www.php.net/manual/en/reflectionclass.getdoccomment.php https://www.php.net/manual/en/reflectionclass.getdoccomment..... Zend has/had support for parsing this value as well. I distinctly remember writing a project in PHP that allowed users to create custom reports and flows based on values returned from the data models, and for whatever reason we decided to use PHPDoc tags to determine what routines would be exposed to the public for use in these tools. We of course eventually updated this to use DB definitions instead because it was an asinine idea to need to parse a bundle of models and other files every time you needed to pull in definitions.

elric 6y ago

Yeah I worded that poorly, but once I went full on caps I decided to leave it, ahem :/. I get the idea of a compile step, and that's totally fine. But these annotations are commented out. It's very icky to be using them for anything other than documentation -- which is what comments are for, after all. Java's annotations are a bit different. Sure, the compiler does things with them -- the runtime does, too --, but they're syntactically part of the language. In PHP, they're kinda of not. Not yet, anyway.

slifin 6y ago
Is a heftier compile step totally fine? The biggest difference between PHP and Java in my mind is that you start Java and pay the compile cost on server start, in PHP you pay the compile cost on every request, frameworks and language features increasingly hide this future cost in caches but caches are one of the two hardest things in computing and often act like pushing things under the carpet, why optimise the compile? It's under the carpet As we move closer and closer to Java's model, we get further and further away from that quick PHP feedback loop of, make a change press f5 see the changes immediately and quickly Which puts us further and further away from the kind of ideals that Bret Victor mentioned in his very good talk inventing on principle: https://youtu.be/PUv66718DII https://youtu.be/PUv66718DII which to quote: "Creators need an immediate connection to what they're creating." Inevitably this is coming and is already here but we should recognise what we've lost
- agustif 6y ago
  Meanwhile with something like NextJS/TypeScript/React you can just enjoy instant reloads without ever caring about F5 again The more languages the better IMHO though
  - purerandomness 6y ago
    Did you just deliberately redefine 'reload' just to incite a flamewar, or do you really not know what's different in your example?
bkanber 6y ago
To be fair, I've been working in PHP for nearly 20 years and I've been able to avoid annotations almost entirely, except for that one time I used Doctrine and then threw it in the trash.

sfteus 6y ago

It absolutely shouldn't, but it _can_: https://www.php.net/manual/en/reflectionclass.getdoccomment.php https://www.php.net/manual/en/reflectionclass.getdoccomment..... Zend has/had support for parsing this value as well. I distinctly remember writing a project in PHP that allowed users to create custom reports and flows based on values returned from the data models, and for whatever reason we decided to use PHPDoc tags to determine what routines would be exposed to the public for use in these tools. We of course eventually updated this to use DB definitions instead because it was an asinine idea to need to parse a bundle of models and other files every time you needed to pull in definitions.