T_PAAMAYIM_NEKUDOTIM, mysql_real_es ape2, parse_str, etc.
> mysql_real_escape2 Blame MySQL for that name, not PHP. https://dev.mysql.com/doc/c-api/8.4/en/mysql-real-escape-str... (And, if you're doing modern PHP, it's just PDO->quote().)
I'm not certain about OP's objection but for me it's less the function name and more the terrible history of how PHP tried to automatically fix SQL injection and instead made everything a thousand times worse. If you're not using bound parameters for user data you're taking a huge risk and making your life multitudes more difficult. PHP's PDO is by far the better option at this point but it suffers from poor enough usability that I've built my own wrapper for it at two different companies.
I'm curious, why do you like getters and setters? I know the textbook answer is so that every single possible property can become some mutable chain of events so you can swap names or side-effects without the caller knowing, but I've yet to find a use for that in real life. It just leads to builder patterns and other oddities like forced decorators like Java has everywhere. I felt like beans were the realization that…
I've always been a fan because if a property turns from a simple value to a more complex interaction that might involve DB operations or other side effects then if a getter is in place you can modify the logic without needing to update widespread code.
If you are replacing a performant property with a slow network call, you are being negligent if you aren't reviewing all the callers to make sure that is okay.
One of the issues with creating a language that is easy to use (PHP, BASIC, and many modern languages), is that people who aren't good at programming, will use it. With predictable results. The difference between languages like PHP and more modern languages, is that the more modern languages have more airbags, for the bad code. It's still bad code, but it won't do as much damage. PHP is likely to be around for a long…
What a condescending point of view.
Which part is condescending? Maybe spell that out?
From what I can see it's some pretty unbiased conclusion that's quite reflective of the truth.
I'm curious, why do you like getters and setters? I know the textbook answer is so that every single possible property can become some mutable chain of events so you can swap names or side-effects without the caller knowing, but I've yet to find a use for that in real life. It just leads to builder patterns and other oddities like forced decorators like Java has everywhere. I felt like beans were the realization that…
They are very useful when modeling CRUD-dy objects, because you can lazy-load infrequently-accessed child object using getters. It makes for a cleaner OOP-y interface in which the caller only cares about actually exposed properties and not methods to get and manipulate hidden properties . IMHO using properties directly is a much more natural way to talk about objects, than having a bunch of methods to get properties.…
I appreciate the detailed answer, thanks. However, It feels like $a->foo vs $a->foo() is a personal preference that hides the fact you're doing work behind the scenes.
Then again, I'm not a fan of code that does magical things that aren't apparent. Makes it a lot harder to 1) reason about and 2) solve performance issues. I also don't want the overhead of function lookups for every property access.
I don't think OP was trying to be condescending. Even if they were, they're still right. A lot of modern languages are designed with bad programmers in mind.
Wasn't trying to be, but it's my experience that people will deliberately assume the very worst intentions, behind whatever I write, so it's a losing proposition, trying to be circumspect. I am, however, pretty against selling crap. If people pay for my work, or even if they don't (most work I do, these days, is free), they have the right to expect that I did good work. I do run into quite a few folks that write crap…
To be honest, it's a pattern I see under every PHP thread:
I'm most excited for property hooks. Having getters and setters as part of the language syntax was something I dearly missed from my C# days, nearly two decades ago. In my projects I sometimes emulate getters and setters using `__get()` and `__set()` but that's heavy-handed and requires lots of PHPDoc annotation for type checking. Property hooks look awesome!
I'm curious, why do you like getters and setters? I know the textbook answer is so that every single possible property can become some mutable chain of events so you can swap names or side-effects without the caller knowing, but I've yet to find a use for that in real life. It just leads to builder patterns and other oddities like forced decorators like Java has everywhere. I felt like beans were the realization that…
Getters are great for manipulating data on the way out. For instance, inside the class you might store a raw representation of the data like a json string, but when reading an attribute you will decode that json string into a datastructure and pluck a certain item. I use dynamic getters often to wrap a raw value with some kind of fallback: do this if no data is present, do this if the data is present but is ancient (ie a seamless upgrade of a v1 internal datastructure to a v2 output), etc. For setters, I try not to have implicit side effects but in certain cases where it makes sense, it is nice to be able to centralize that logic: "if this value changes, ensure x and y occur" which you get "for free throughout your codebase when you use a setter, versus having to go thru the entire codebase and sprinkle the do_x() and do_y() calls (which then becomes additional footprint to maintain and worry about)
> mysql_real_escape2 Blame MySQL for that name, not PHP. https://dev.mysql.com/doc/c-api/8.4/en/mysql-real-escape-str... (And, if you're doing modern PHP, it's just PDO->quote().)
I'm not certain about OP's objection but for me it's less the function name and more the terrible history of how PHP tried to automatically fix SQL injection and instead made everything a thousand times worse. If you're not using bound parameters for user data you're taking a huge risk and making your life multitudes more difficult. PHP's PDO is by far the better option at this point but it suffers from poor enough u…
Writing a wrapper for PDO is standard operating procedure for various good reasons.
I don't think OP was trying to be condescending. Even if they were, they're still right. A lot of modern languages are designed with bad programmers in mind.
One thing I'd like to highlight though is that there were mountains of terrible advice out there around PHP from novices who had figured out a way to make things work - around the time of PHP 5.3 the community ran an ambitious initiative to crawl through sites like Stack Overflow and replace bad answers with correct ones. The community realized how dangerous it was for novices and how much all the bad advice was hurting the reputation of the language and they took decisive action to fix it.
Separately, IMO, languages should always be designed with bad programmers in mind - good programmers are going to figure out the right way to do things in any language but bad programmers are going to fire off every foot gun they can find. PHP has made efforts to remove or de-emphasize foot guns and it has evolved into a much safer tool to give someone.
I find it pretty fascinating that what used to be a beginner-friendly language, with limited capabilities but that is very easy to get started with, has now evolve to a bloated monster full of advanced features that you can't expect to know entirely, with a complex framework and tooling ecosystem to support it. PHP lovers generally don't like acknowledge that, but the PHP we've learned back-end development two decade…