101–110 of 127 posts
Earlier quoted context omitted.
Its a syntax problem then ? what if the annotation wasn't inside comments would that make it ok ?
A lot of this boils down to PHP's feeble "array" declarator. Take a page from JavaScript and make it easy.
This is pure horse pucky. First of all PHP isn't about elegance and I find it a teeth grinding experience when people complain about it not being so. PHP is about getting stuff done. He doesn't offer one good valid technical reason why not to use comments for meta-programming PHP other than "it just feels wrong" and an "icky feeling" which is entirely subjective. "Reliance on Yet Another Library"? C'mon. The fact tha…
This implies that the road not taken by PHP (and thus the roads taken by other languages) are somehow unproductive. That's not accurate. Most languages are about getting stuff done. A tool can be explicit, or elegant, or whatever, and also help you get stuff done.
You are basically saying that PHP's design is at a global maximum for productivity and this is simply not true.
This is pure horse pucky. First of all PHP isn't about elegance and I find it a teeth grinding experience when people complain about it not being so. PHP is about getting stuff done. He doesn't offer one good valid technical reason why not to use comments for meta-programming PHP other than "it just feels wrong" and an "icky feeling" which is entirely subjective. "Reliance on Yet Another Library"? C'mon. The fact tha…
"PHP is about getting stuff done." This implies that the road not taken by PHP (and thus the roads taken by other languages) are somehow unproductive. That's not accurate. Most languages are about getting stuff done. A tool can be explicit, or elegant, or whatever, and also help you get stuff done. You are basically saying that PHP's design is at a global maximum for productivity and this is simply not true.
Earlier quoted context omitted.
A lot of this boils down to PHP's feeble "array" declarator. Take a page from JavaScript and make it easy.
As of PHP 5.4 you can use [] to define arrays. It saves some typing, and is less noisy on the eyes I guess.
Earlier quoted context omitted.
I disagree. > First of all PHP isn't about elegance...PHP is about getting stuff done. What language isn't about getting stuff done? > He doesn't offer one good valid technical reason why not to use comments... Not true. The OP explicitly points out that it breaks many PHP debugging capabilities. > The fact that you can even parse out comments with the reflection API lends, to me, that meta-programming is a-ok. So wh…
Many of the OPs complains have the tone of "not my PHP!!!". If old PHP devs learn to look for annotations, points 2 and 4 no longer apply, and many points in 1 no longer apply either. It sounds more like a PHP dev grumbling about change... (what else is new)
Having a proper `pragma` declaration would be ideal.
Earlier quoted context omitted.
You can be intuitively against something, but not be able to work out why. A few hours later, you often realize the rational reasons behind your original feeling.
Indeed, but what if you don't? I'm not saying that intuition is bad. I'm saying that intuition is bad when trying to make a reasonable point.
Though I did make one (hopefully reasonable) point that it fuzzes the lines between code and explanation of that code, which I don't care for. The article also gives a valid reason that tools are not expecting this and won't correctly accommodate (though that could be considered a short-term problem).
Earlier quoted context omitted.
> ...because I have other shit I need to do. Ironically, that's often also the attitude of programmers who don't use comments in their code (in any language).
To be fair, writing meaningful comments is really hard. So hard that the number of people who do it well is a small fraction of even the otherwise best programmers. To make matters worse, poor comments are worse than no comments at all. I can see why many programmers shy away from them. * Comments that describe what the code does are a complete waste of time. The code already tells you what it does. * Comments that d…
Comments within the code should be used to highlight things that are not what they seem. They should answer any "WTF?" questions that naturally arise. A typical example is something like "Hack: Need to pass fifth argument as -1 to avoid crash in broken library".
Comments that act like descriptive audio are useless.
Point by point:
1. dx regressions
I've designed the annotation system so that if developers misdeclare them an exception is thrown. Unit tests will fail, and the software will not run. Someone checking in code that fails to such a degree deserves what's coming to them. That covers php -l. Var_dump and debug_backtrace are irrelevant to my use case, and I use proper breakpoints and watches anyway (phpstorm + zend debugger). I don't even understand the point he's trying to make about IDE linking. Which leaves the argument about comment folding, which I think has some merit, if you think comments shouldn't be read, which I don't.
2. Readability
Nonsense. Learning an API always requires getting used to its idiosyncracies. His proposal to use static variables looks less readable to me.
3. Reliance on another library
Yes, that's kind of the point.
4. Icky feeling
Aha, bingo. The author came in with the opposite bias of myself and drew an according conclusion.
To conclude: the use of annotations in comments is not better or worse than alternatives, it's all in the eye of the beholder.
This is pure horse pucky. First of all PHP isn't about elegance and I find it a teeth grinding experience when people complain about it not being so. PHP is about getting stuff done. He doesn't offer one good valid technical reason why not to use comments for meta-programming PHP other than "it just feels wrong" and an "icky feeling" which is entirely subjective. "Reliance on Yet Another Library"? C'mon. The fact tha…
"PHP 5 comes with a complete reflection API that adds the ability to reverse-engineer classes, interfaces, functions, methods and extensions. Additionally, the reflection API offers ways to retrieve doc comments for functions, classes and methods." [1]
It's an awesome way to generate automatic documentation for big projects. Of course it's possible to use it for other stuff like pointing to a template (though I'll point out that it can be done faster and more obviously by replacing it with a single function call at the end of the method), but "right tool for the job" and all that.
There's a very widely understood premise in programming that comments are blocks of text in source code files intended only to be read by humans and have no effect on program execution. When you change the semantics of something so well-defined... God help you.
Also worth noting in your sample code is that many ORMs simply query the DB for the schema and cache that result, so you don't need either of those. Merely being able to connect to your database is sufficient. The former comment (@Column) is a nice, short, human-readable format so developers can see what a column is, but having your code execution depend on that is crazy. What happens if someone minified [2] the code? Or ran it through a bytecode accelerator [3]?
I'm not going to stop anyone from abusing comments in their own codebase, but I sure as hell won't let this behavior infect mine.
[1]: http://www.php.net/manual/en/intro.reflection.php [2]: Yes, I know that's pointless in server-side source code - doesn't stop it from happening. [3]: http://www.php.net/manual/en/reflectionclass.getdoccomment.p...
Earlier quoted context omitted.
To be fair, writing meaningful comments is really hard. So hard that the number of people who do it well is a small fraction of even the otherwise best programmers. To make matters worse, poor comments are worse than no comments at all. I can see why many programmers shy away from them. * Comments that describe what the code does are a complete waste of time. The code already tells you what it does. * Comments that d…
Comments regarding methods should be added to clarify how they are intended to be used, and what the results should be expected to be. Comments within the code should be used to highlight things that are not what they seem. They should answer any "WTF?" questions that naturally arise. A typical example is something like "Hack: Need to pass fifth argument as -1 to avoid crash in broken library". Comments that act like…
As I mentioned before, it seems the number of people who can actually pull off good comments are exceedingly small. I've looked at some prolific open source projects that have a decent amount commenting around method definitions as you suggest is good practice, but found the comments to be no more enlightening than just looking at the source code itself. I will assume they were just poor examples.
I do agree with everything else you said though.