requiring additional php files requires additional processing power consumption
if its that what you were asking.
php has to stat the files, load it, parse it, etc.
Heh, I figured as much. Hm...
I think that answers my question.
I figured that the PHP engine has to include the file, interpret what it included (which involves the stuff that you don't intend for the consumer of a library to use as well as the stuff the consumer will use), and make any functions within the included file available to the consumer.
So, hmmm... the next bit is knowing if it takes more processing power to read a new file in than to have a bunch of extra stuff in the included file.
Or, rather, more time ... processing power might be even less, but the file itself might take more time because of having to stat it, read the file in, etc.
It's just a whole side of things I haven't had to think about until now.
With a compiled language, you know that the compiler has done some up-front work in dealing with all this stuff, and the output is something that's kind of streamlined to do what you need. Not exactly the same with a scripting language, where an interpreter has to parse everything in advance.
Recursive functions tend not to come all the way back down the stack if they have a statement like "sys.exit(0)" in them.
<< SMH >>
I spent half a day rewriting code and ultimately wondering whether Python actually has recursion before finding that I had put that trace point in my function. /me needs either more coffee or less, dunno which...
As a general rule, I avoid exit() statements, preferring to use block structures and whatnot, for reasons like this.
Unfortunately, apparently, in PHP, using nested blocks is discouraged according to a popular standard of style used by that community, as they regard nested blocks as 'difficult to read'.
I disagree, but conform to their standards when working with others.
Heh... I expect it stopped cold dead rather nicely.
Recursive functions tend not to come all the way back down the stack
if they have a statement like "sys.exit(0)" in them.
<< SMH >>
I spent half a day rewriting code and ultimately wondering whether
Python actually has recursion before finding that I had put that trace
point in my function. /me needs either more coffee or less, dunno
You'reDoingItWrong(tm). Sys.exit(1) in Python is implemented as an exception throw. So it's actually the perfect with to terminate a recursion. Catch SysExit or whatever they call it, and you're golden. <snirk>
throw "yo dawg, I heard u liek trace messages FIXME YOU IDIOT";
You'reDoingItWrong(tm). Sys.exit(1) in Python is implemented as an
exception throw. So it's actually the perfect with to terminate a
recursion. Catch SysExit or whatever they call it, and you're golden.
I've since switched to throwing exceptions when I want the program to come to a screeching halt.
The only problem is, Python doesn't allow you to throw an exception.
doesn't work. You can't throw an exception; you have to RAISE an exception.
F--k that ... ! If I want to throw an exception, I'm going to throw an exception!
Even if it's just an exception thrown from the fact that there's no "throw" command!
Having lived mostly in the C world for decades, though, I can see already that exception handling justifies all sorts of sloppy programming practices.
Why write good code when you can just wrap the whole damn thing in an exception handler?
Python is ugly, but yet python is beautiful :
I used to think exceptions were the bomb.
Now I just think they're a bomb. I prefer more explicit error handling with return codes or the like. I hate having the flow interrupted randomly by who-knows-what deep in the layers of hell.
I guess it has its place, though... I just haven't quite decided for myself where that place should be.
I just read a question that kind of blows my mind.
"I don't understand why cURL come into play? I thought this was using rest?
is cURL a type of rest client?"
(I copied the question literally, punctuation and capitalization errors and all).
That last question blows my mind. Is cURL a type of REST client?
It's one of those questions that exposes what feels like a fundamental misunderstanding of several subtle but important concepts. I'm thankful someone else answered it for him, because I'm not sure how I would have started without coming across as a jerk.
How does that question feel to you guys?
Well, I used exception for that, and re-threw it enriching the error message all the way up the stack; Else you would have to keep some string some where... so exceptions make it more nice.
He/she/it should be using libcurl, not the cURL "client"
Why write good code when you can just wrap the whole damn thing in an
Been dealing with our Junior Dev(tm) who did just that, this week. No, you can't just write crap in the exception handler and assume that it will never be hit.
To be clear, I knew cURL is spelled correctly, however 'is cURL a type of rest client?" has a variety of capitalization problems, which is more along the lines of what I meant about preserving the original. I wasn't making fun of the person's English skills, or even meaning to comment on them, only to indicate that those were not my errors.
me loves jshint.