I like it. Would be smart to add some kind of picture for sharing Facebook is more successful if people not just see text.
lol. downvotes for wanting to share someone's idea. that one I really don't get...
PHP: The Right Way
201–210 of 233 posts
Re: PHP: The Right Way
#202Earlier quoted context omitted.
The problem is not Java, but some types of architects that flourish in corporations, usually doing designs with endless numbers of abstractions, layer upon layer. I've seen this happening in C, followed by C++, and now Java and C#. They will do it regardless of the language being used.
This is an excellent point. I so often attribute my disdain to Java itself when, in reality, the issue is the majority of Java engineers. Java itself can be a beautifully terse language.
"terse" is about the last word that I would use to describe Java.
Compared to almost every other language I've had exposure to, it's more verbose.
Re: PHP: The Right Way
#203Earlier quoted context omitted.
I think the whole point here is why does PHP even have references like that. Right now the only mainstream language I know that does that is C++ and well, its C++ and mutable references are actually not frequently used in practice. Most other languages stay with pass by value most of the time and PHP references kind of look like a leaky abstraction from the underlying C implementation...
I use references for passing around large arrays of data for instance, rather than having copies made all over the place (class instances are passed by reference no matter what you do).
What I meant is that people usually pass things via a pointer (that needs to be explicitly dereferrenced) or via const references (where there is no mutation to worry about). Mutable references are rarer and usually they are function arguments and are relatively "obvious"
Re: PHP: The Right Way
#204Earlier quoted context omitted.
Using '\' as a namespace seperator? Just off the top of my head, there are probably loads more.
I've actually gotten used to it (and I rallied against it heavily). It's really not so bad; it's even somewhat nice it has a file-system like connotation. PHP's design precluded using any existing operators.
Based on how long it took to introduce the ability to say foo()["bar"], I'm guessing it's not the language so much as it's a set of poorly designed parser rules.
Also, magically, I can't use empty(functionResult()); but I can say $result = functionResult(); empty($result);
Re: PHP: The Right Way
#205As a part-time PHP hater who often has to work with it professionally, I believe this is a fantastic resource. The bit on databases in particular is something that all PHP devs should read. That said, it is difficult to bring a legacy code base in line with modern style, though you can improve it over time. Also, this could benefit from some other gotchas, extremely surprising behavior and best practices for avoiding…
On a database section, I am not a fan of PDO and I choose native interfaces like mysqli for my DAO layer or opt for something high level like ORM depending on the requirements. But it goes without saying that protection from SQL injection is a must, it is just PDO's statement binding is not the only way. MySQLi does support data binding, and for others it is easy to DIY using sprintf and whatever is the escaping meth…
You can use PDO to connect and run queries without using all the crazy variable binding features.
Re: PHP: The Right Way
#206Earlier quoted context omitted.
I've actually gotten used to it (and I rallied against it heavily). It's really not so bad; it's even somewhat nice it has a file-system like connotation. PHP's design precluded using any existing operators.
Based on how long it took to introduce the ability to say foo()["bar"], I'm guessing it's not the language so much as it's a set of poorly designed parser rules. Also, magically, I can't use empty(functionResult()); but I can say $result = functionResult(); empty($result);
> I'm guessing it's not the language so much as it's a set of poorly designed parser rules.
There are poorly designed parser rules but the namespace operator is not due to that. It's due to the fact that a single PHP file will be compiled to byte code without knowing what the symbols represent until runtime. The separate operator is needed because names are resolved before execution begins and before the symbols are known.
> Also, magically, I can't use empty(functionResult()); but I can say $result = functionResult(); empty($result);
Empty is identical to the not (!) operator except that empty() can operate on undefined variables, undefinted array keys, or undefined properties. empty(functionResult()) doesn't make any sense because functionResult() can never be an undefined variable. You just use !functionResult().
Re: PHP: The Right Way
#207Earlier quoted context omitted.
The problem is not Java, but some types of architects that flourish in corporations, usually doing designs with endless numbers of abstractions, layer upon layer. I've seen this happening in C, followed by C++, and now Java and C#. They will do it regardless of the language being used.
This is an excellent point. I so often attribute my disdain to Java itself when, in reality, the issue is the majority of Java engineers. Java itself can be a beautifully terse language.
I usually don't like to put "beautiful" and "terse" next to each other. "expressive", maybe, but terse? That sounds like an insult.
Re: PHP: The Right Way
#208Earlier quoted context omitted.
Input is almost always filtered. Without mincing the semantics of that, let's say you receive free-form NL query as input. You don't filter that to reduce it to core terms you send to the database? You don't remove prepositions? You don't tokenize at all? Input is ambiguous and reduced/filtered into pseudo-meaningful terms to return relevant output.
If I want to tweet I you could pre-encode that as safe to paste into raw SQL, or as well-formed (X)HTML, but you can't do both simultaneously. Either encoding would end up distorting the content in the other context. You have to encode during output (and writing to a database counts) using the rules of the system consuming that output. Lots of crappy web forums visibly mangle punctuation in a futile effort to avoid t…
What a great example. I am going to remember that one.
Re: PHP: The Right Way
#209I like it. Would be smart to add some kind of picture for sharing Facebook is more successful if people not just see text.
lol. downvotes for wanting to share someone's idea. that one I really don't get...
Probably because your comment is extremely difficult to understand and looks a lot like spam.
Re: PHP: The Right Way
#210Earlier quoted context omitted.
Sure, but you defined ptr outside of the loop. Who defined $object outside of the loop in the PHP example? Also note that, in C, you have to explicitly dereference pointers: ptr = 42; You should get a warning from your compiler if you try that. PHP effectively goes ahead and changes it to: *ptr = 42; Perl requires you to explicitly dereference references as well: @array = ('c', 'c++', 'java', 'perl'); $item = \$array…
WTF. Sometimes I wonder if I'm being unfairly prejudiced by not learning PHP myself and making my own decision about it but things like this make me change my mind.
I thought this for a long time as well. I always enjoyed ragging on PHP but wondered if it was just because I wasn't familiar with it.
A few months ago, I got the opportunity to do a little PHP programming. I was wrong. I didn't have a bad impression of PHP simply out of ignorance. In fact, my opinion of the language is now much lower than before. I honestly can't conceive how anyone could legitimately defend it for anything other than its ubiquity.