Comment On EnterFlag Technology

You mean like... Grand Canyon? Haha.

"It works on MY machine"
Similar to the expression I hear from construction contractors, "Can't see it from MY house!"

{In a former life, I worked on new construction sites}

will $_POST['submit'] always exist? ($_SERVER['REQUEST_METHOD'] could come in handy)

That's completely unparseable.

the REAL WTF is the existence of perl.

Marvelous.... Just marvelous....

The 'submit' solution came to my mind just directly after the problem hit me.

Sometimes I wish I was a computer to just feel what it is like when people throw stuff like that at it..... Oh, the horror.

- Unomi -

AC:

That's completely unparseable.

the REAL WTF is the existence of perl.

Dude, that's PHP.

I hate PHP.

Perl Guy:

AC:

That's completely unparseable.

the REAL WTF is the existence of perl.

Dude, that's PHP.

Whatever, they're both ridiculous.

AC:

the REAL WTF is the existence of perl.

It's PHP.

PHP *is* the bastard child of Perl: all the idiosyncrasies, nuances, and stupidities of Perl with more security holes than you can shake a script-kiddie at.

I loathe PHP.

JamesKilton:

PHP *is* the bastard child of Perl: all the idiosyncrasies, nuances, and stupidities of Perl with more security holes than you can shake a script-kiddie at.

I loathe PHP.

Now, now. Like with everything else, hate the user, not the tool. PHP is decent if it's used properly (and no, I don't use it myself). The problem is its easy to pick up so every moron who thinks he's a developer grabs it and starts to hack away.

Anonymous belgian:

will $_POST['submit'] always exist? ($_SERVER['REQUEST_METHOD'] could come in handy)

$_POST will always exist, but may be empty, and if $_POST['submit'] doesn't exist, then the isset() returns false, which is the point.

JamesKilton:

...with more security holes than you can shake a script-kiddie at.

Sure, if you're using PHP 4 and not changing the default settings. But that would be kind of like installing Windows ME with no firewall or anti-malware software... you get what you deserve.

JamesKilton:

PHP *is* the bastard child of Perl: all the idiosyncrasies, nuances, and stupidities of Perl with more security holes than you can shake a script-kiddie at.

I loathe PHP.

Who is this poor woman Perl, and why are people denigrating her illegitimate child PHP? Oh, the humanity of it all...

JamesKilton:

PHP *is* the bastard child of Perl: all the idiosyncrasies, nuances, and stupidities of Perl with more security holes than you can shake a script-kiddie at.

Not true! It doesn't have *all* the nuances. Just the icky ones. The nuances which actually make sense, the nuances you can do spiffy things, those are all missing.

All the suckiness of Perl without any of the goodness like proper closures. =)

> I loathe PHP.

I felt like that only when I had to maintain legacy code (wich was ported from ASP), but then came php5 with all those nice thingies (SPL, PDO, SimpleXML).

On the subject of Perl, I think everyone should learn a good text processing language, and I believe that Perl is that language. There are so many useful things that Perl can do for you, to just stick with C# or C++ or C or even Java to accomplish tasks that perl can accomplish faster is just maddening. I frequently compare what I can do in C++ or C to what I do in Perl (that is, text processing and the like), and I find that Perl is much faster to write, and saves my ass where other languages wouldn't.

You can complain about perl not being 'pretty', but don't knock the language -- it is by far one of the most robust languages out there.

There seems to be no end to these kind of wtfs. It seems so basic: if your goal is something that would seem to be something commonly done, odds are there is already a way to do it.

Perl Guy:

it is by far one of the most robust languages out there.

:-D Have you ever thought of doing stand-up comedy?

TheRubyWarlock:

Now, now. Like with everything else, hate the user, not the tool.

I challenge people who say this to write secure, readable Intercal code, for, say, processing a simple CGI form. Yes, the user makes a huge difference, but some tools are certainly better than others, and PHP leaves a lot to be desired.

On a serious note, I would like to challenge all those who hate PHP to list what web technology they use.

I can come up with some really good reasons to NOT use all the popular web technologies just as easily as everyone can come up with reasons to hate PHP.

I'm not saying I love PHP or anything but as far as web technologies go, there isn't much out there that doesn't make my skin crawl.

While I don't really know PHP and am too lazy to understand everything that is going on, what I'm seeing here is a file path of 'a', meaning that this moron is creating this file on the 3.5" disk. Correct?

It's not hard to write good stable secure php code. It's also not hard to write crappy exploitable code. In fact it's pretty easy to make something that works, but works in the worst ways imaginable. PHP has come a long way since register_globals = TRUE.

You missed the biggest WTF. Once one person hits the page, everyone "already hit enter".

Improper use of global resources.

jread:

While I don't really know PHP and am too lazy to understand everything that is going on, what I'm seeing here is a file path of 'a', meaning that this moron is creating this file on the 3.5" disk. Correct?

The $this->flagPath variable is the path to the file, the 'a' is the mode that the file is opened in (a for append, in this case).
php.net/fopen

Jazz:

Anonymous belgian:

will $_POST['submit'] always exist? ($_SERVER['REQUEST_METHOD'] could come in handy)

$_POST will always exist, but may be empty, and if $_POST['submit'] doesn't exist, then the isset() returns false, which is the point.

But what if the form is submitted by a method other than the submit button? ISTR that, at least in some browsers, simply hitting enter while the form is in focus will submit the form without activating the submit button, thus $_POST['submit'] will not be set. $_SERVER['REQUEST_METHOD'] would seem the more reliable, assuming you POST the form.

That parameter is an access flag for file IO.

'a' - Open for writing only; place the file pointer at the end of the file. If the file does not exist, attempt to create it.

Perl Guy:

You can complain about perl not being 'pretty', but don't knock the language -- it is by far one of the most robust languages out there.

I like Perl, because no matter how late it is, no matter how drunk I am, no matter what the hell I type in, the interpreter will parse it, and I can say "my work is done."

If you have an:

<input type="submit" name="submit" value="Go" />

Then it over-rides the JS:

var f = document.getElementById('myForm');
f.submit();

This is due to legacy support, where the fields (by name) are siblings to the form reference.

So they might have removed the 'name' attribute on the form, instead of using a different one... this would have 'broken' the original detection method.

Personally, I prefer an additional:

<input type="hidden" name="act" value="submit" />

Then to not use a 'name' attribute on the submit input.

This is because some browsers don't pass the name/value pair if the user just presses the [enter] key, instead of using the submit button.

But that's just me... I'm weird.

:-D

This is a good example of why I do not accept freelance projects maintaining existing PHP code.

def report(request):

    if request.method == 'POST':

        form = MyForm(request.POST)

        if form.is_valid():

            # do something...

    else:

        form = MyForm()

    return render(request, "myform.htm", locals())

Re: PHP hatred

Yes, PHP is the popular language-to-hate du jour. I must confess to having a bit of a love-hate relationship with PHP myself, though. As a long-time PHP developer (all the way from PHP3 to PHP5) I have seen the good, band and the ugly of this language. On the one hand, there were some maddening shortcomings in design (getting better, tho), and in implementation, but on the other hand, use any language/environment long enough and it begins to fit like a comfortable old shoe. Once you learn to a) keep things simple and b) steer clear of the major stupidities, such as register_globals and interspersing HTML and code, you can accomplish an amazing amount of work with it. I especially like the fact that I can dynamically call objects and functions ($objecname->$functionname() and even variables with $$variablename. It's a nice shorthand for what require more roundabout methods in many other languages. Of course, I tend to eschew typical OO-with-inheritance for OO-by-composition, which works quite well in PHP because of the above.

PHP3 was a toy, PHP4 was an ungainly mess, but *many* of the standard complaints have been fixed in the 5 releases. (Now, if we can just get namespaces, closures with lexical scoping, and a better method of mapping arrays to function arguments, I would be happy overall with the language. Make functions first-class objects as in Javascript and I am ecstatic.)

Yah... purists are horrified that PHP arrays are *all* implemented internally as hashes, but that provides one benefit you don't get in most languages: no type-casting between different collection types; an array can be a collection of anything. This makes them quite flexible, and the inefficiency of hashes is only a problem if you intend to build huge arrays with complex manipulations (in which case you shouldn't be using PHP, period). For most normal usage, performance is fine. For example, I tested an array of 100,000 sub-arrays, each with at least 20 elements, and I saw no noticeable delay. My PHP runtime (command-line version) expanded to about 15 MB of RAM, I believe.

Now this isn't to say I prefer PHP for all things. Currently I am having a major fling with Ruby, while two-timing it with Python for some more serious Unix systems stuff, but I still think PHP has its place, and would rather use it any day than deal with the monstrous bureaucracy that is Java.

rycamor:

Yah... purists are horrified that PHP arrays are *all* implemented internally as hashes, but that provides one benefit you don't get in most languages: no type-casting between different collection types; an array can be a collection of anything.

I would argue that this should count as a feature for the other languages, and not a deficiency =)

Maciej:

rycamor:

Yah... purists are horrified that PHP arrays are *all* implemented internally as hashes, but that provides one benefit you don't get in most languages: no type-casting between different collection types; an array can be a collection of anything.

I would argue that this should count as a feature for the other languages, and not a deficiency =)

Well, OK then argue it. I'd like to hear it.

"Hate the user, not the tool." What if the user is a tool? ;)

Edgeman:

The $this->flagPath variable is the path to the file, the 'a' is the mode that the file is opened in (a for append, in this case).
php.net/fopen

Ah, thanks for the explanation. So, is it telling us what the path is or is that part not shown in the code?

Spoe:

Jazz:

Anonymous belgian:

will $_POST['submit'] always exist? ($_SERVER['REQUEST_METHOD'] could come in handy)

$_POST will always exist, but may be empty, and if $_POST['submit'] doesn't exist, then the isset() returns false, which is the point.

But what if the form is submitted by a method other than the submit button? ISTR that, at least in some browsers, simply hitting enter while the form is in focus will submit the form without activating the submit button, thus $_POST['submit'] will not be set. $_SERVER['REQUEST_METHOD'] would seem the more reliable, assuming you POST the form.

It doesn't matter, that's just a "shortcut" for pressing the submit button (it still triggers onsubmit, etc.)

rycamor:

Well, OK then argue it. I'd like to hear it.

OK. Arrays and hashes are not functionally identical. Many (if not most) algorithms that make sense when used with one do not make sense with the other. Languages that provide a distinction between the two allow programming errors to be detected by the language interpreter/compiler, while still allowing for the (rare, in my opinion) case where one needs to convert between the two. Hence, enforcing a distinction between hashes and arrays may be considered a feature.


Addendum (2007-07-30 13:47):
I tried the 100,000 sub-array test, and the following code made PHP use up 180Mb of memory:

$x = array();

for ($i=0; $i< 100000; $i++) {

        $x[$i] = array();

        for ($j=0; $j<20; $j++) {

                $x[$i][$j] = $j;

        }

}

For comparison (and I don't mean to imply that this proves that Perl is superior to PHP), the equivalent Perl code took up 1/3 the memory.

LiquidFire:

It doesn't matter, that's just a "shortcut" for pressing the submit button (it still triggers onsubmit, etc.)

As a test, I made short form consisting of a text input and a submit button. In firefox, yes, it acts as though you pressed the submit button: the submit field was submitted. In IE7, however, it wasn't. Thus, I can't see that relying on the presence of the submit field for much of anything.

Naw naw man, you got it all wrong.
Hate the GAME, not the playa'!

Captcha: onomatopoeia

jimlangrunner:

"Hate the user, not the tool." What if the user is a tool? ;)

You just made my day :-)

Am I the only person wondering if $this->flagPath is unique for each load or a constant?

Maciej:

rycamor:

Well, OK then argue it. I'd like to hear it.

OK. Arrays and hashes are not functionally identical. Many (if not most) algorithms that make sense when used with one do not make sense with the other. Languages that provide a distinction between the two allow programming errors to be detected by the language interpreter/compiler, while still allowing for the (rare, in my opinion) case where one needs to convert between the two. Hence, enforcing a distinction between hashes and arrays may be considered a feature.


Addendum (2007-07-30 13:47):
I tried the 100,000 sub-array test, and the following code made PHP use up 180Mb of memory:

$x = array();

for ($i=0; $i< 100000; $i++) {

        $x[$i] = array();

        for ($j=0; $j<20; $j++) {

                $x[$i][$j] = $j;

        }

}

For comparison (and I don't mean to imply that this proves that Perl is superior to PHP), the equivalent Perl code took up 1/3 the memory.

Yes, I would expect Perl to be more efficient in this. And I admit after checking that I was wrong about the 20 sub-elements (it was a couple years ago). Actually it was 7. It was for an app that executes a C program to extract metadata from very large TIFF files. In that case, each sub-array was more like:

array(
"xwidth" => 2544,
"yheight" => 3295,
"xres" => 300,
"yres" => 300,
"resunit" => 2,
"colordepth" => 1,
"type" => "mono"
);

And in this case, the 100,000 elements were not loaded at full-speed, because there was plenty else going on in the app, including waiting a few microseconds between each row of meta-data, received from STDIN.

Anyway, this still demonstrates the difference between purity and real-life usage. For practical matters, why make a tabular structure of 100,000 elements in PHP when PHP has databases available everywhere? SQLite is built-in, in fact. I only did the test as a pathological case, because the system was intended to handle documents up to about 5,000 pages (the practical limit of a large TIFFs for many other reasons).

Sure, if you are doing DNA mapping or modeling large networks, I don't recommend PHP in the least, but that's not its purpose. As for your other point about enforcing type distinctions, it sounds like you're quoting right out of your comp/sci textbook. Real-world usage patterns for PHP don't tend to run into problems with this, unless the programmer is clueless about how PHP handles arrays (and then there are usually much worse problems in the code ;) ).

Not to be a total PHP apologist, though. I know its warts better than most people, but at least they are predictable and avoidable.

anon:

Perl Guy:

You can complain about perl not being 'pretty', but don't knock the language -- it is by far one of the most robust languages out there.

I like Perl, because no matter how late it is, no matter how drunk I am, no matter what the hell I type in, the interpreter will parse it, and I can say "my work is done."

... undef.

rycamor:

Maciej:

rycamor:

Yah... purists are horrified that PHP arrays are *all* implemented internally as hashes, but that provides one benefit you don't get in most languages: no type-casting between different collection types; an array can be a collection of anything.

I would argue that this should count as a feature for the other languages, and not a deficiency =)

Well, OK then argue it. I'd like to hear it.

Can't believe you haven't heard it before, really. It's quite simple.

You have, essentially, three choices. You can have a collection of "class X," you can have a collection of "class X and derived classes," or you can have a collection of "object."

For some bizarre reason, the details of which escape me right now, the latest version of Java has moved away from 'collection of "object".' I am distraught. What am I going to do with all those exceptions I used to get?

A collection of "class X" is fine, but a little limiting. Most sane languages, these days, go for 'collection of "class X and derived classes."' Even that is open to abuse, but at least it's abuse in the programmer space, not in the compiler/interpreter space.

So, then. You have an "array" -- so-called -- which is a "collection of anything."

What's to prevent this, now or in the future, from being "a big bag o'shit?"

I'd advise going back and reading a few basic books on data structures, myself.

Having been there before (and many times), I have finally learned to use the frigging request method. Seriously, what's up with the hidden "do=action" fields? Do they even realize that if someone tries to upload a file that's too large for the post request, none of the post data will actually arrive?

$_SERVER['REQUEST_METHOD'] = 'GET' when the form is called, 'POST' when it's submitted.

There, wasn't that easy.

(What's that - you use a GET form to submit content to the server? I didn't hear that.)

"I wouldn't be able to find my own ass if it weren't for Google, and my programming skills mostly involve copy&pasting code from codeproject.com. Go ahead and hire me."

"Uh, you know what? No."

Am I the only person wondering if $this->flagPath is unique for each load or a constant?

It's constant. That's not as bad as it sounds, though, because the form will only be filled out once per setup (it's configuration stuff for accessing the database and so on).

real_aardvark:

rycamor:

Maciej:

rycamor:

Yah... purists are horrified that PHP arrays are *all* implemented internally as hashes, but that provides one benefit you don't get in most languages: no type-casting between different collection types; an array can be a collection of anything.

I would argue that this should count as a feature for the other languages, and not a deficiency =)

Well, OK then argue it. I'd like to hear it.

Can't believe you haven't heard it before, really. It's quite simple.

The request was in the rhetorical sense.

You have, essentially, three choices. You can have a collection of "class X," you can have a collection of "class X and derived classes," or you can have a collection of "object."

For some bizarre reason, the details of which escape me right now, the latest version of Java has moved away from 'collection of "object".' I am distraught. What am I going to do with all those exceptions I used to get?

A collection of "class X" is fine, but a little limiting. Most sane languages, these days, go for 'collection of "class X and derived classes."' Even that is open to abuse, but at least it's abuse in the programmer space, not in the compiler/interpreter space.

What does this have to do with Java? I thought we were discussing PHP.

Anyway, I understand this is a serious theoretical questions that can be discussed at length on lambda-the-ultimate.org, and honestly even further if you go into literature on logic and mathematics. In fact, reading "Gödel, Escher, Bach", you would see that this question goes back to the beginnings of mathematics. You have the "strict typists", who try to reduce everything to self-contained logical levels, and then you have those who insist that this approach runs smack dab into Gödel's incompleteness theorem, and that there is nothing wrong with a "typeless" system as long as you define the rules of usage.

So, then. You have an "array" -- so-called -- which is a "collection of anything."

What's to prevent this, now or in the future, from being "a big bag o'shit?"

An assertion wrapped in the guise of a question that in a sense does beg the question.

I'd advise going back and reading a few basic books on data structures, myself.

Ahh yes...fresh out of C.S., got the world all figured out, can dispense at a glance with anyone who doesn't parrot the received knowlege in the correct phrasing. Go and read just a few books and get back to me.

Of course I'm not saying that any collection should be typeless. Even in PHP it is quite easy to make a structure that maintains your types, but that's not the only way to approach things.

PHP reminds me of VB 6 in many ways. Perhaps the biggest difference is that ON ERROR RESUME NEXT is turned on by default.

rycamor:

real_aardvark:

rycamor:

Maciej:

<snip>
I would argue that this should count as a feature for the other languages, and not a deficiency =)

Well, OK then argue it. I'd like to hear it.

Can't believe you haven't heard it before, really. It's quite simple.

The request was in the rhetorical sense.

No, no, no. You can have a rhetorical question. You cannot have a rhetorical request. That would be rather against the rules. And even if it were within the rules, you would have to pose it (a) as one sentence, not two, or (b) within the time-honoured XML format of <rhetorical> ... cretinous gubbins ... </rhetorical>.

rycamor:

real_aardvark:

You have, essentially, three choices. <snip>

What does this have to do with Java? I thought we were discussing PHP.

I'm not sure what you're discussing, mate. I happen to loathe Java, and oddly enough think that PHP is a perfectly good RAD to demonstrate a (completely non-scalable) solution to a (disgustingly Web-based) application. It's about as good as it gets. Which isn't saying much.

rycamor:

Anyway, I understand this is a serious theoretical questions that can be discussed at length on lambda-the-ultimate.org, and honestly even further if you go into literature on logic and mathematics. In fact, reading "Gödel, Escher, Bach", you would see that this question goes back to the beginnings of mathematics. You have the "strict typists", who try to reduce everything to self-contained logical levels, and then you have those who insist that this approach runs smack dab into Gödel's incompleteness theorem, and that there is nothing wrong with a "typeless" system as long as you define the rules of usage.

Frankly, I think Hofstadter got off lightly with that particular piece of shit. Sophomoric arguments about whether a particular mathematical system is, or is not, either consistent or complete hardly relate to the piles of boiling crap that so much of the IT industry produces.

rycamor:

real_aardvark:

So, then. You have an "array" -- so-called -- which is a "collection of anything."

What's to prevent this, now or in the future, from being "a big bag o'shit?"

An assertion wrapped in the guise of a question that in a sense does beg the question.

Okey dokey. If I've wrapped this up as an assertion inside a question, let's try replacing "which is a" with "which appears to be" ... even though that was actually a quote from you. But no matter. It is no longer an assertion. It is a genuine question. Care to answer it?

rycamor:

real_aardvark:

]I'd advise going back and reading a few basic books on data structures, myself.

Ahh yes...fresh out of C.S., got the world all figured out, can dispense at a glance with anyone who doesn't parrot the received knowlege in the correct phrasing. <snip ... sorry>

Twenty years out of it, in fact. Still trying to figure the world out. Still questioning received knowledge.

Still not willing to listen to the C.S. equivalent of Esalen or Christian Science. Make sense or get outta here, and leave it to the professionals.

rycamor:

Anyway, this still demonstrates the difference between purity and real-life usage. For practical matters, why make a tabular structure of 100,000 elements in PHP when PHP has databases available everywhere? SQLite is built-in, in fact. I only did the test as a pathological case, because the system was intended to handle documents up to about 5,000 pages (the practical limit of a large TIFFs for many other reasons).

Because, of course, relational databases always suit any given problem better than in-memory data structures. Goodness, yes.

My personal reason for loathing PHP is the weak typing. I quite like dynamic typing (I'm a Lisp programmer) but I draw the line at weak typing.

Oh, that and 'magic_quotes', of course. There's a special hell involving proofreading endless documents with lots of random backslashes inserted awaiting the person who invented 'magic_quotes'