PHP Tutorial: Well, that's one way to do it...
-
Our second method, getValueByFieldName will use a foreach loop to search through all GET/POST variables. It will return the value of the variable that has the same name as what was passed as a parameter to the method.function getValueByFieldName($a_str_fieldName) { foreach($_REQUEST as $key => $value) { if(strtolower($key) == strtolower($a_str_fieldName)) { return $value; } } }
-
Bonus points for using both camelCase AND underscore_style in the same variable name.
-
[quote user="Pap"]Bonus points for using both camelCase AND underscore_style in the same variable name.[/quote]
Somewhat related to one of the prominent criticisms of PHP.
Some functions use camelcase:
http://www.php.net/manual/en/function.dom-domelement-setattributenode.php
Some use underscores:
Some don't use underscores:
They can't settle on one or the other, even in their own library functions. That was one nice thing about Java. They defined at the outset exactly how functions, classes, and variables should be named (camelcase, w/ or w/o the initial char capitalized, depending on context). If you know a function is called "do something", you don't have to try to remember if it's actually do_something(), dosomething(), or doSomething().
-
I don't do much PHP (thank god) but I don't know of a better way to pull a value out of a hash table case-insensitively - actually, I can't think of one in any language, not just PHP.
@Pap said:
Bonus points for using both camelCase AND underscore_style in the same variable name.
Yeah, almost as bad as using both spaces AND full stops to seperate words.
-
@iwpg said:
I don't do much PHP (thank god) but I don't know of a better way to pull a value out of a hash table case-insensitively - actually, I can't think of one in any language, not just PHP.
Non-edit (stupid timeout): this is in languages where hash-tables are normally case-sensitive, of course.
-
The preferences for Mozilla products is the same way. Go to about:config if you're using Firefox and take a look.
-
[quote user="iwpg"]I don't do much PHP (thank god) but I don't know of a better way to pull a value out of a hash table case-insensitively - actually, I can't think of one in any language, not just PHP.[/quote]
I hope you're not a programmer, because that is a drop-dread easy problem:
$_REQUEST[strtolower($key)]
-
@bobday said:
[quote user="iwpg"]I don't do much PHP (thank god) but I don't know of a better way to pull a value out of a hash table case-insensitively - actually, I can't think of one in any language, not just PHP.
I hope you're not a programmer, because that is a drop-dread easy problem:
$_REQUEST[strtolower($key)]
[/quote] And what if they key in the hash table isn't lowercase?
-
[quote user="iwpg"][quote user="bobday"]
[quote user="iwpg"]I don't do much PHP (thank god) but I don't know of a better way to pull a value out of a hash table case-insensitively - actually, I can't think of one in any language, not just PHP.[/quote]
I hope you're not a programmer, because that is a drop-dread easy problem:
$_REQUEST[strtolower($key)]
[/quote] And what if they key in the hash table isn't lowercase?[/quote]
I think that's a case of "don't do that."
-
@Anonononymous said:
[quote user="iwpg"][quote user="bobday"]
And what if they key in the hash table isn't lowercase?[/quote]$_REQUEST[strtolower($key)]
I think that's a case of "don't do that."
[/quote]
Except in PHP, $_REQUEST is controlled by the user, and $key is (usually) controlled by the program. So, if you're going to be case insensitive at all, presumably you want to account for case differences in the keys of $_REQUEST.
-
[quote user="iwpg"] Except in PHP, $_REQUEST is controlled by the user, and $key is (usually) controlled by the program. So, if you're going to be case insensitive at all, presumably you want to account for case differences in the keys of $_REQUEST.[/quote]
Well, $_REQUEST is controlled by the client, which in many cases you're also writing (or someone on a cooperating team is). If you're providing an API which anyone can write to, simply specify that the key is case-sensitive. Sending the request with keys in the wrong case is rejected as an invalid request.
-
@Anonononymous said:
[quote user="iwpg"] Except in PHP, $_REQUEST is controlled by the user, and $key is (usually) controlled by the program. So, if you're going to be case insensitive at all, presumably you want to account for case differences in the keys of $_REQUEST.
Well, $_REQUEST is controlled by the client, which in many cases you're also writing (or someone on a cooperating team is). If you're providing an API which anyone can write to, simply specify that the key is case-sensitive. Sending the request with keys in the wrong case is rejected as an invalid request.
[/quote]
Right, hence the "if you're going to be case insensitive at all". ;-)
-
[quote user="merreborn"]
Somewhat related to one of the prominent criticisms of PHP.
Some functions use camelcase:
http://www.php.net/manual/en/function.dom-domelement-setattributenode.php
Some use underscores:
Some don't use underscores:
They can't settle on one or the other, even in their own library functions. That was one nice thing about Java. They defined at the outset exactly how functions, classes, and variables should be named (camelcase, w/ or w/o the initial char capitalized, depending on context). If you know a function is called "do something", you don't have to try to remember if it's actually do_something(), dosomething(), or doSomething().
[/quote]
Actually, the first two are pretty consistent in PHP. Normal functions such as array_slice use underscores (usually, at least; never camel case though). Class methods such as DOMElement->setAttributeNode use camel case (though these methods may be available as normal functions, using them that way is definitely not recommended or used by any sane programmer).
-
[quote user="Dragnslcr"]Actually, the first two are pretty consistent in PHP. Normal functions such as array_slice use underscores (usually, at least; never camel case though).[/quote]
Just look through the function reference, there is very little consistency at all. Many sections do stick to one convention or the other but many of the bigger sections don't. There are often very closely related functions like htmlentities and html_entity_decode that are named inconsistently.
-
[quote user="iwpg"]I don't do much PHP (thank god) but I don't know of a better way to pull a value out of a hash table case-insensitively - actually, I can't think of one in any language, not just PHP.[/quote]
You should learn perl
sub getValueByFieldName { return @request{grep { lc $_ eq lc $fieldname} keys %request}; }
-
@ailivac said:
You should learn perl
sub getValueByFieldName { return @request{grep { lc $_ eq lc $fieldname} keys %request}; }
That's basically the same as the code in the OP, just with a grep instead of an explicit loop. Oh, and your version may return multiple results, whereas the original will only return the first it finds.
-
@iwpg said:
Oh, and your version may return multiple results, whereas the original will only return the first it finds.
In fact, your version is almost the same when called in scalar context, except it returns the last match (not that ordering is well-defined for hash tables, at least in Perl). Strangely enough, maybe I'm not looking in the right place, but the only place I could find this documented was in a blog post from a little over a year ago.
-
[quote user="iwpg"][quote user="iwpg"]Oh, and your version may return multiple results, whereas the original will only return the first it finds.[/quote] In fact, your version is almost the same when called in scalar context, except it returns the last match (not that ordering is well-defined for hash tables, at least in Perl). Strangely enough, maybe I'm not looking in the right place, but the only place I could find this documented was in a blog post from a little over a year ago.[/quote]
This is because the results of a hash slice are a list, rather than an array (in Perl, these are somewhat different creatures.) In scalar context, the binary comma operator returns its rightmost operand (this is documented in perlop.) Thus a comma-separated list evaluates to its rightmost element in scalar context.
-
[quote user="friedo"]
This is because the results of a hash slice are a list, rather than an
array (in Perl, these are somewhat different creatures.) In scalar
context, the binary comma operator returns its rightmost operand (this
is documented in perlop.) Thus a comma-separated list evaluates to its rightmost element in scalar context.[/quote]
Yeah. that's what it said on the blog. It's still non-obvious, though, and should IMHO be explicitly documented that slices work this way - especially given that there weren't any actual commas in the code under discussion.
-
Someone forgot to note that function names in PHP are case-insensitive... Variables are a different story though, and you can't write $_request. But you can write HTMLEntities().
PHP is annoying sometimes, and difficult to get tidy, but is MUCH better IMO than ASP, which uses lobotomizing BASIC-like syntax, or Perl, which is even less tidy (English Wikipedia classifies it as an esoteric programming language...) Also, PHP is easy to learn for someone who is proficient in C or Java.
-
@stinch said:
Just look through the function reference, there is very little consistency at all. Many sections do stick to one convention or the other but many of the bigger sections don't. There are often very closely related functions like htmlentities and html_entity_decode that are named inconsistently.
Yeah, that can get pretty annoying. It's one of the things that everyone wishes would be changed, but backwards compatibility dictates never will. I was referring more to underscores vs. camel case, which is consistent.
-
@Anonononymous said:
[quote user="iwpg"] Except in PHP, $_REQUEST is controlled by the user, and $key is (usually) controlled by the program. So, if you're going to be case insensitive at all, presumably you want to account for case differences in the keys of $_REQUEST.
Well, $_REQUEST is controlled by the client, which in many cases you're also writing (or someone on a cooperating team is). If you're providing an API which anyone can write to, simply specify that the key is case-sensitive. Sending the request with keys in the wrong case is rejected as an invalid request.
[/quote]No need to even specify that, $_REQUEST implies HTTP and I'm fairly sure GET and POST parameters are defined as case-sensitive anyway.
-
I cannot believe $_REQUEST is case sensitve. I do not work with php often, but i know asp.net is case insensitve.
Doesnt make sense that it would be senstive mainly because $_REQUEST contains the GET array. And it is possible for user input within the GET, which case can be varying.
-
Array keys are case sensitive in PHP because some specifications require it and people might want to use arrays in code handling such specifications. For $_REQUEST those specifications are not just mainly HTTP GET, POST and COOKIE variables but solely those because that's all the array stores. Whether a developer needs to treat the user value as case-sensitive or not depends on the application.
As for ASP.net, I don't use it at all but I am convinced it supports case-sensitive operations on both keys and values - otherwise it would be completely useless for anything dealing with HTTP parameters, passwords, certain CAPTCHAs, spelling/grammar checks.Almost sounds like you agree with me though; and that your disbelieve comes from a reversed understanding of the terms case-sensitive and case-insensitive.
-
Maybe im not understanding your use of the terms case-sensitive and case-insensitive.
When dealing with asp.net i can access a posted form field with the name 'key' with Form["KEY"] or Form["key"]. In that fact im am saying it is case insensitive, any case of the key will access the value. The same is for cookies and querystrings.
Acessing the value if the key though will always be in the case it was sent, case-sensitive.
-
While you are right that $_REQUEST is controlled by the user, it's the application developer who determines what parameters are valid. They are free to specify that parameters are case-sensitive and not recognize those with incorrect case.
If you have to be case-insensitive, then by all means, just lower or upper everything you receive and stay internally consistent. You may not control what is given to you, but you control what you accept and what you do internally.
And as a PHP developer, I'd like to agree with everybody balking at the inconsistencies in PHP, especially in its naming scheme. Not only are underscores used at random, but functions with similar or inverse functions don't always have similar names, nor are their arguments always in the same order (which comes first, the needle or the haystack?). There was some definite lack of planning involved when these decisions were made--a decision that will have to be lived with at this point.
PHP: array_slice - Manual
