Heh, thankfully I don't have to support PHP versions that old (although PHP 5.2 might as well be). It's called Requests for PHP to disambiguate it from Kenneth Reitz's fantastic Requests library in Python, which also serves to inspire my library.
PHP coded this way seems as sexy than java or c# without still the consistency of those languages.
What is the advantage of using PHP now?
The code is overbloated with complexity thus close to unmaintanable (evolution and correction) and there are stuff that feels wrong in my guts: https://github.com/rmccue/Requests/blob/master/library/Reque... the naming is WRONG: flattening a list is not what he is doing: it is transforming a nested data structure in a level 1 associative array. Each wrong naming is a landmine waiting to explode at your face.
This language now strikes me as an odd frankenstein that has no advantages anymore for coding.
And this code is hiding its weakness in ridiculously complex OOP: every single methods are static for me it is the sign it should have been a namespace exporting functions.
Not disputing or supporting your particular point about the style here, but problems with PHP as a language and problems with PHP as coded by a particular developer are two different things.
Weirdly, people seem to ascribe the latter to the former rather often around here.
The same rant can be made on PHP and this code is just a very vivid example of this point.
PHP is not a fractal of bad design, a language is primarily a media to convey ideas and concept from human to humans and actually if the culture of the users is sub level, whatever the quality of the language is the code will be shitty.
PHP has attained a critical mass of ignorant developers that are dragging not only their whole language down but also of the whole eco system (managers, sysadmins...), so PHP is not only a bad language it is also a bad culture we should try to eradicate :)
Is someone forcing you to use PHP? If you don't like it, don't use it. If you don't like the culture, then by all means, either try to improve it or don't participate in it. Luckily, the universe of software is large enough that you need never touch PHP if you don't want to. PHP is just a tool, one which many developers find useful, and which yes supports a lot of shitty code. Go make an app in Django or Rails or... whatever. The world is your oyster.
But the idea that it should be 'eradicated' is just plain silly. If we eradicated every language some random purist found offensive we'd be left coding in raw binary.
And yes I am forced to use PHP or any cited bullshitware because all these coders are intoxicating my customers with false hope, and false expectations that after close lookups (especially the Total Cost of Ownership including maintaining) systematically fail to deliver what was promised.
Would you listen to someone who says coding correctly takes time but maintaining will be easy or the enthusiasts that are saying I have a framework that "works" (but is not) and I can deliver in no time? (disregarding the actual quality of the code they are using, or the operational complexity (thus additional recurring costs), or ignoring the big O notations). Advocates of BSware don't care about the details. But the devil lies in the details.
There is no shortcut for being a decent programmer; you have to have the control over everything.
I say it loud and clear: because of their culture some language and tools turn decent smart people into incompetent frauds that contaminate the work of every developers. Incompetency is a cancer that contaminates the economy and costs an awful lots of bucks.
By all means then... because we are all thoroughly tired of bloat, conceptual flaws and security issues in our code... enlighten we simple peons as to the language we should rather be writing our web apps in.
And you can't say C, because PHP is already a wrapper for C, and of course PHP is terrible.
> The code is overbloated with complexity thus close to unmaintanable (evolution and correction) and there are stuff that feels wrong in my guts: https://github.com/rmccue/Requests/blob/master/library/Reque.... the naming is WRONG: flattening a list is not what he is doing: it is transforming a nested data structure in a level 1 associative array. Each wrong naming is a landmine waiting to explode at your face.
Uh, ok? What would you propose naming it then? transformNestedDataStructureIntoALevelOneAssociativeArray? The only person this might seem fundamentally wrong to would be a first-year computer science student prepping for a test on a standard library - names are chosen by the author for the context.
> This language now strikes me as an odd frankenstein that has no advantages anymore for coding.
What a novel idea. Perhaps it "strikes" you that way, despite the fact that many people still use PHP for some reason.
> And this code is hiding its weakness in ridiculously complex OOP
Static methods are "complex OOP"?
> every single methods are static for me it is the sign it should have been a namespace exporting functions.
That "strikes me" as a design choice. Furthermore, in PHP the autoloading convention is to translate the class and the namespace to a file path (PSR-0); there isn't a convention like this for namespaced functions. Furthermore, namespaced functions are not that backwards compatible.
I am not a PHP fan myself, although I have used it in the past, and it seems to me like you just want to jump on the anti-PHP bandwagon for fun. Your criticism is pedantic and shallow.
I don't suppose you could share your best code so the HN community can criticize it to the point of breaking and use that as a straw man argument to wipe your language of choice off the face of the planet?
As evidenced by all sorts of open source software, you can write horrendous things in the most elegant and designed of languages.
Yes, PHP has quite a mongrel history. But it has its uses, and its spheres of excellence. The past couple of years have seen a great increase in concerted efforts to improve the language and to introduce a more robust and disciplined ecosystem.
(I know I really shouldn't feed the trolls, but these arguments always annoy me so lets put this down to a one-time rant.)
The question in this case is, why am I doing ridiculously stupid things in PHP? Why am I using static methods as an excuse for namespacing?
The answer is backwards compatibility. Requests has to work on the majority of hosts out there, which includes PHP 5.2. Namespaces were only introduced in PHP 5.3, so I can't make use of them (although I wish I could). If this was written for new, modern versions of PHP, there would be a lot of changes.
The same would be true for any interpreted language: you have to aim for the lowest common denominator with widely distributable software. I'm sure there are Python developers out there who've been itching to use Python 3 features for ages, but it's only just becoming viable to do so.
As for the flatten bit, it's turning an associative array into a positional array by concatenating the key and value as per RFC2616, which I can't really fit in a function name. To be honest, I didn't put a lot of thought into that function since it's for internal use only anyway. I'd love to hear any other things that bother you though.
Also, thanks to those defending my code in the comments, but suffice to say it's not perfect.
Would love to see an example of Requests and the JSON api in WordPress, i.e. how would on go about making secure authenticated connections with a WordPress install through the JSON api. Is that in the works?
https://github.com/rmccue/WP-API-Client is an example of using Requests with the API (and the reference client fir the API), but it's not secure authentication, it's just a secure connection. The way to do that is to a) enable SSL on your site, and b) point the client to the HTTPS version of your site. That's all you need to use the security features in Requests.
30 comments
[ 4.7 ms ] story [ 73.4 ms ] threadIs there anything special to consider when using it with the Laravel framework?
Not that I'm aware of, you should be able to simply use it as a normal library.
I wasn't confused by the title on the linked-to page, separating the version number from the name helped.
The code is overbloated with complexity thus close to unmaintanable (evolution and correction) and there are stuff that feels wrong in my guts: https://github.com/rmccue/Requests/blob/master/library/Reque... the naming is WRONG: flattening a list is not what he is doing: it is transforming a nested data structure in a level 1 associative array. Each wrong naming is a landmine waiting to explode at your face.
This language now strikes me as an odd frankenstein that has no advantages anymore for coding.
And this code is hiding its weakness in ridiculously complex OOP: every single methods are static for me it is the sign it should have been a namespace exporting functions.
Weirdly, people seem to ascribe the latter to the former rather often around here.
The language brings a culture and the efficiency of a language is indissociable from its average programming culture.
The rant of torvalds against C++ for coding is not about the language but the culture of the developers. http://article.gmane.org/gmane.comp.version-control.git/5791...
The same rant can be made on PHP and this code is just a very vivid example of this point.
PHP is not a fractal of bad design, a language is primarily a media to convey ideas and concept from human to humans and actually if the culture of the users is sub level, whatever the quality of the language is the code will be shitty.
PHP has attained a critical mass of ignorant developers that are dragging not only their whole language down but also of the whole eco system (managers, sysadmins...), so PHP is not only a bad language it is also a bad culture we should try to eradicate :)
But the idea that it should be 'eradicated' is just plain silly. If we eradicated every language some random purist found offensive we'd be left coding in raw binary.
And yes I am forced to use PHP or any cited bullshitware because all these coders are intoxicating my customers with false hope, and false expectations that after close lookups (especially the Total Cost of Ownership including maintaining) systematically fail to deliver what was promised.
Would you listen to someone who says coding correctly takes time but maintaining will be easy or the enthusiasts that are saying I have a framework that "works" (but is not) and I can deliver in no time? (disregarding the actual quality of the code they are using, or the operational complexity (thus additional recurring costs), or ignoring the big O notations). Advocates of BSware don't care about the details. But the devil lies in the details.
There is no shortcut for being a decent programmer; you have to have the control over everything.
I say it loud and clear: because of their culture some language and tools turn decent smart people into incompetent frauds that contaminate the work of every developers. Incompetency is a cancer that contaminates the economy and costs an awful lots of bucks.
And you can't say C, because PHP is already a wrapper for C, and of course PHP is terrible.
I'm sorry, but that sounds like a lot of vague buzzwordy hand-waving and my bullshit meter is ringing.
Uh, ok? What would you propose naming it then? transformNestedDataStructureIntoALevelOneAssociativeArray? The only person this might seem fundamentally wrong to would be a first-year computer science student prepping for a test on a standard library - names are chosen by the author for the context.
> This language now strikes me as an odd frankenstein that has no advantages anymore for coding.
What a novel idea. Perhaps it "strikes" you that way, despite the fact that many people still use PHP for some reason.
> And this code is hiding its weakness in ridiculously complex OOP
Static methods are "complex OOP"?
> every single methods are static for me it is the sign it should have been a namespace exporting functions.
That "strikes me" as a design choice. Furthermore, in PHP the autoloading convention is to translate the class and the namespace to a file path (PSR-0); there isn't a convention like this for namespaced functions. Furthermore, namespaced functions are not that backwards compatible.
I am not a PHP fan myself, although I have used it in the past, and it seems to me like you just want to jump on the anti-PHP bandwagon for fun. Your criticism is pedantic and shallow.
As evidenced by all sorts of open source software, you can write horrendous things in the most elegant and designed of languages.
Yes, PHP has quite a mongrel history. But it has its uses, and its spheres of excellence. The past couple of years have seen a great increase in concerted efforts to improve the language and to introduce a more robust and disciplined ecosystem.
(I know I really shouldn't feed the trolls, but these arguments always annoy me so lets put this down to a one-time rant.)
The question in this case is, why am I doing ridiculously stupid things in PHP? Why am I using static methods as an excuse for namespacing?
The answer is backwards compatibility. Requests has to work on the majority of hosts out there, which includes PHP 5.2. Namespaces were only introduced in PHP 5.3, so I can't make use of them (although I wish I could). If this was written for new, modern versions of PHP, there would be a lot of changes.
The same would be true for any interpreted language: you have to aim for the lowest common denominator with widely distributable software. I'm sure there are Python developers out there who've been itching to use Python 3 features for ages, but it's only just becoming viable to do so.
As for the flatten bit, it's turning an associative array into a positional array by concatenating the key and value as per RFC2616, which I can't really fit in a function name. To be honest, I didn't put a lot of thought into that function since it's for internal use only anyway. I'd love to hear any other things that bother you though.
Also, thanks to those defending my code in the comments, but suffice to say it's not perfect.
https://github.com/rmccue/WP-API-Client is an example of using Requests with the API (and the reference client fir the API), but it's not secure authentication, it's just a secure connection. The way to do that is to a) enable SSL on your site, and b) point the client to the HTTPS version of your site. That's all you need to use the security features in Requests.
Expect a PR from me in the near future :D