And this is why I hate PHP (again)
-
BobJanova wrote:
Or you can use "... $s[recid] ... etc" (note no single quotes in the array indexer).
I like that, strange nuance though it may seem, and will try out shortly. Assuming it works, Thanks!
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"As far as we know, our computer has never had an undetected error." - Weisert
"If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
-
Well, that's another one that I'll probably remember. I always use your second tip, (the one with the array keys concatenation), it's the closest to what I'm used to doing. 10x for the tip, good to know :thumbsup:. I also really miss the StringBuilder. Doing large numbers of string concatenations, dunno, just feels wrong) EDIT: I think I'll be partying today (First discussion I've opened to be featured in The Daily News Newsletter :laugh: )
Full-fledged Java/.NET lover, full-fledged PHP hater. Full-fledged Google/Microsoft lover, full-fledged Apple hater. Full-fledged Skype lover, full-fledged YM hater.
Another thing you may wish to look into if you've not already: "HEREDOC". If you consider that .php is very heavily used as a language for server-side web development, then you may realize that sometimes there's quite a bit of formatted HTML that may need to be generated. This can be done very easily using the "<<<" operator (HEREDOC). It allows you to actually create the entire webpage (if you wished to) as a single string in a natural webpage format. Or type in paragraph after paragraph of text to create a string, embedding $variables as you go along. Syntax:
$lotsOfStuff = <<
HUSBAND WIVES
Scaramouche Kimberley
$here $hellion[1],$hellion[2]... etc
someName;Examples that come to mind: - JavaScript that are modified at load - Design page-pieces in HTML, cut & paste them into your HEREDOC block, and then modify as required. The entire page (
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"As far as we know, our computer has never had an undetected error." - Weisert
"If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
-
BobJanova wrote:
Or you can use "... $s[recid] ... etc" (note no single quotes in the array indexer).
I like that, strange nuance though it may seem, and will try out shortly. Assuming it works, Thanks!
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"As far as we know, our computer has never had an undetected error." - Weisert
"If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
That's bad bad bad and more BAD advice. Always use quotes around array indexes in PHP if not what you are essentially telling php is that there is a defined constant with the name of recid, PHP looks for it and doesn't find it, and replaces it with the string 'recid' and generating a E_NOTICE error for you. For more info see here: http://de.php.net/manual/en/language.types.array.php#language.types.array.foo-bar[^] Member 8857022 showed the correct way of doing this using {} to wrap the variable.
-
This is caused by a piece of PHP weirdness combined with a browser getting confused about mismatched tags. The PHP weirdness is that the ternary is a weak binding. So
$var = $bool ? 1 : 0 . ' bowls of petunias';
... will set $var to either (numeric) 1 or (string) "0 bowls of petunias". This isn't wrong, per se, but it is surprising if you come from a language where the ternary is a strong binding. In PHP you must do
$var = ($bool ? 1 : 0) . ' bowls of petunias';
As a result of that, you're outputting markup with mismatched <td>/</td> tags, if the ternaries pick the first option. If that inside a nested table, most browsers will just give up on trying to work out what's going on and draw the contents of the mismatched cells before the inner table.
I don't like PHP either, but this looks like a simple matter of operator precedence to me. The precedence of operators is well defined in PHP. +/-/. have higher precedence than ?:, so the outcome is IMO reasonable, and in no way weird. Consider this: x == 2 ? 14 : 2 * 7. Would you expect "* 7" to be evaluated after the ?: in this case? Some people recommend redundant parentheses precisely for avoiding such situations - it's not just a matter of correctness, it's also a matter of expressiveness - the variant without parantheses is potentially misleading, even when it's intended.
-
W∴ Balboos wrote:
(who NEVER eats bacon)
Burn the heretic!
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
OriginalGriff wrote:
Burn the heretic!
Crispy, I would suppose. (Sigh)
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"As far as we know, our computer has never had an undetected error." - Weisert
"If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
-
I, on the contrary, really enjoy .php, but - being an amazingly nice guy (who NEVER eats bacon), I'll give you a watch-out-for: If you are outputting results from an array (such as might be returned from dbase calls), you'll have any number of rowsets which might, for example, become the conents of a table. Let's say each rowset in array $Data contains such the fields 'recID', 'name', 'age', and you wish to iterate through a loop to generate a table. You might try to use something like:
foreach ($Data as $d)
ECHO "$d['recid']$d['name']$d['age']";You'll typically get an error mentioning problems with whitespaces. As it turns out, .php doesn't like the array item's referenced inside the "'s The solutions are either:
foreach ($Data as $d)
ECHO "".$d['recid']."".$d['name']."".$d['age']."";or
foreach ($Data as $d) {
$r = $d['recid'];
$n = $d['name'];
$a = $d['age'];
ECHO "$r$n$a";
}You may employ the later approach if you've other symbols you'd like in your "-ed output
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"As far as we know, our computer has never had an undetected error." - Weisert
"If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
There is an easier way to do this. You should be able to write:
foreach ($Data as $d)
ECHO "{$d['recid']}{$d['name']}{$d['age']}";From the PHP Manual:
Quote:
Enclose the variable name in curly braces to explicitly specify the end of the name.
http://www.php.net/manual/en/language.types.string.php#language.types.string.parsing[^]
-
As I recall (been a while since I worked in PHP), you can make those array references work in string if you add curly brackets:
foreach ($Data as $d)
ECHO "${d['recid']}${d['name']}${d['age']}";I think the curly braces go before the
$. -
There is an easier way to do this. You should be able to write:
foreach ($Data as $d)
ECHO "{$d['recid']}{$d['name']}{$d['age']}";From the PHP Manual:
Quote:
Enclose the variable name in curly braces to explicitly specify the end of the name.
http://www.php.net/manual/en/language.types.string.php#language.types.string.parsing[^]
This solution was posted a bit ago. http://www.codeproject.com/Feature/WeirdAndWonderful.aspx?fid=392254&select=4324500&fr=1#xx0xx[^] - This user, however, put the $ outside of the curly braces. I actually end up doing what you could describe as the long-hand of the two options I suggested: reassigning the variables to non-array. There's method to this madness, though, as the data I usually work with is coming from a database and some amount of preprocessing is often necessary before it's ready for display. The curly braces method, however, I'll keep in mind for there's places where readability would be improved.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"As far as we know, our computer has never had an undetected error." - Weisert
"If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
-
Yeah, this is what was happening in my case. Thanks for the explanation and alternate fix! :thumbsup: On a side note, I think I'll start compiling a list of 'Look out for...', and glue it to a wall in the office. Maybe in this way, other poor souls will not fall into the same pit of agony as me and my team did these last few weeks (most of us come from Java, and some also have a bit of .NET experience)
Full-fledged Java/.NET lover, full-fledged PHP hater. Full-fledged Google/Microsoft lover, full-fledged Apple hater. Full-fledged Skype lover, full-fledged YM hater.
<blockquote class="FQ"><div class="FQA">Andrei Straut wrote:</div>Full-fledged Java/.NET lover, full-fledged PHP hater.</blockquote>
You must separate things, try using Yii framework and see about good pratices on PHP. PHP is very powerful depends on the way you use. http://www.yiiframework.com/[^]
-
This is caused by a piece of PHP weirdness combined with a browser getting confused about mismatched tags. The PHP weirdness is that the ternary is a weak binding. So
$var = $bool ? 1 : 0 . ' bowls of petunias';
... will set $var to either (numeric) 1 or (string) "0 bowls of petunias". This isn't wrong, per se, but it is surprising if you come from a language where the ternary is a strong binding. In PHP you must do
$var = ($bool ? 1 : 0) . ' bowls of petunias';
As a result of that, you're outputting markup with mismatched <td>/</td> tags, if the ternaries pick the first option. If that inside a nested table, most browsers will just give up on trying to work out what's going on and draw the contents of the mismatched cells before the inner table.
BobJanova wrote: The PHP weirdness is that the ternary is a weak binding. And it's left associative. Which means:
<?php
$i = 2;
echo ($i <= 3) ? "Three or less" :
($i > 3) ? "Over 3" :
"Whaaaat?";outputs "Over 3" because it is interpreted as:
<?php
$i = 2;
echo (($i <= 3) ? "Less than three" : ($i > 3)) ?
"Over 3" :
"Whaaaat?"; -
[begin rant] So, I've been doing some integrations between our company Oracle E-Business Suite ERP and a website from a company that has been recently acquired by us. Our ERP exposes a webservice that our main website and the newly acquired company's website need to call, and sync clients, orders, products, etc (the two websites are e-commerce). So, I had to make a module for the new company website, and have that module call the ERP webservice with the needed data. The new company website is PHP. Now, I also had to output some data in some tables that would show up as a webpage full of logs, when I found a PHP bug (I guess it's a bug, cause if it's not, then it's elephanting plain weird). So let's say we have:
[outputting some unrelated table stuff]
[...]$result .= ''.date('d-m-Y g:i A', strtotime($header->getCreatedTimestamp())).'';
$result .= ''.(intval($header->getPlacedTimestamp() != 0)) ? 'Yes' : 'No' .''; // doing it directly screws everything up, this td and the one below are shown before the table
$result .= ''.(intval($header->getPlacedTimestamp() != 0)) ? $header->getPlacedTimestamp() : '-' .'';
$result .= ''.$header->getSupplierName().'';[outputting other unrelated table stuff]
[...]So, imagine my surprise when the result of the two ternaries gets placed BEFORE THE GODDAMNED TABLE!!! I mean, the output is:
[Ternaries result]
[table with my other data, no result from the two ternaries whatsoever, and the td's are simply missing]And the fix was simply to place the ternary result into two variables, and output those (I guess those two get somehow evaluated and executed before the other code, or I just don't know):
[outputting some unrelated table stuff]
[...]
$is_placed = (intval($header->getPlacedTimestamp() != 0)) ? 'Yes' : 'No';
$placed_ts = (intval($header->getPlacedTimestamp() != 0)) ? $header->getPlacedTimestamp() : '-';
$result .= ''.date('d-m-Y g:i A', strtotime($header->getCreatedTimestamp())).'';
$result .= ''. $is_placed .''; // doing this works, the tds are shown correctly, in their places
$result .= ''. $placed_ts .'';
$result .= ''.$header->getSupplierName().'';[outputting other unrelated table stuff]
[...]Oh, and I also had to output the HTML table from PHP code (as a requirement, I had to follow their...'guidelines', which enforce this :wtf: ) [end rant] Edit: Sorry, I just had to get this thing off my chest. I thin
Might work if the brackets are in the right place ;)
(intval($header->getPlacedTimestamp() != 0)) ? 'Yes' : 'No';
should be
(intval($header->getPlacedTimestamp()) != 0) ? 'Yes' : 'No';
This is why I hate PHP sometimes. How the original code doesn't at least generate a warning is beyond me...
Need a mobile website? http://mobidoo.com.au
-
That's bad bad bad and more BAD advice. Always use quotes around array indexes in PHP if not what you are essentially telling php is that there is a defined constant with the name of recid, PHP looks for it and doesn't find it, and replaces it with the string 'recid' and generating a E_NOTICE error for you. For more info see here: http://de.php.net/manual/en/language.types.array.php#language.types.array.foo-bar[^] Member 8857022 showed the correct way of doing this using {} to wrap the variable.
This is NOT TRUE when we're talking about array lookups inside a double quoted string. See here[^]: the example includes an unquoted string indexer. PHP won't try to resolve recid in the context of a double quoted string. You can use the braced syntax but it is unnecessary complexity to do so when there is a well defined shortcut.
-
This is NOT TRUE when we're talking about array lookups inside a double quoted string. See here[^]: the example includes an unquoted string indexer. PHP won't try to resolve recid in the context of a double quoted string. You can use the braced syntax but it is unnecessary complexity to do so when there is a well defined shortcut.
That's stupid, how would you go about using a defined constant as an array index within a double quoted string then? You would have to resort to the curly braces. This means there is a double standard, one when you are outside a double quoted string and one when you are inside. (My point here is not that PHP is a bad language it is that "quirks" such as this shouldn't be seen as a feature of a language) If that is true I would argue its not a well defined shortcut if you have to apply the rule "well it works in that situation but not in this situation" However, I still stand by my statement that it is not a good idea under any circumstance to tell people to use $array[index] as opposed to $array['index'] even in the case where it may work without generating a E_NOTICE error, the chance of the user misunderstanding and using it in other places simply because it works is too high.
-
That's stupid, how would you go about using a defined constant as an array index within a double quoted string then? You would have to resort to the curly braces. This means there is a double standard, one when you are outside a double quoted string and one when you are inside. (My point here is not that PHP is a bad language it is that "quirks" such as this shouldn't be seen as a feature of a language) If that is true I would argue its not a well defined shortcut if you have to apply the rule "well it works in that situation but not in this situation" However, I still stand by my statement that it is not a good idea under any circumstance to tell people to use $array[index] as opposed to $array['index'] even in the case where it may work without generating a E_NOTICE error, the chance of the user misunderstanding and using it in other places simply because it works is too high.
ItsTobias wrote:
This means there is a double standard, one when you are outside a double quoted string and one when you are inside.
Well, uh, yeah. Different contexts have different rules in every language. That's why you can write code inside a method but not in a class in C#, for example, or why you can't have 'local methods' in Java: because class, method, double-quoted-string etc are different contexts and different rules apply.
However, I still stand by my statement that it is not a good idea under any circumstance to tell people to use [context dependent syntax], the chance of the user misunderstanding and using it in other places simply because it works is too high.
I generalised your quote to indicate what you're actually saying. If the context isn't clear (for example if you can use something inside a loop but not inside an if block, or something like that) then sure, but when the context rule is simple then I don't agree. Learning the rules of each context is part of learning a language.
-
ItsTobias wrote:
This means there is a double standard, one when you are outside a double quoted string and one when you are inside.
Well, uh, yeah. Different contexts have different rules in every language. That's why you can write code inside a method but not in a class in C#, for example, or why you can't have 'local methods' in Java: because class, method, double-quoted-string etc are different contexts and different rules apply.
However, I still stand by my statement that it is not a good idea under any circumstance to tell people to use [context dependent syntax], the chance of the user misunderstanding and using it in other places simply because it works is too high.
I generalised your quote to indicate what you're actually saying. If the context isn't clear (for example if you can use something inside a loop but not inside an if block, or something like that) then sure, but when the context rule is simple then I don't agree. Learning the rules of each context is part of learning a language.
I agree learning rules about when you can and cant do certain things in a programming language is important and therefore there are context dependent rules for every language that must be learned from an early point. However I do not feel that (in this situation) within a double quoted string is enough of a context switch to cause the user to feel like they are now applying a different rule set. This is especially true in this specific case because PHP will let you do the wrong thing(use un-qouted array indexes outside double quoted strings), other languages, if you apply the context rules in the wrong place you will likely get errors thrown at you and your code will not run (be it a compiled or scripted language) however in PHP in this specific situation(context) the PHP engine will "fix" your incorrect code, almost silently (How silent it is about this depends on your systems error display level), since this is a scripted language PHP has to fix your code every time. Since the user is none the wiser about their error, they will keep doing it that way in the future because "it just works", and then you end up with questions like "This works on my dev box but when I upload it to my live machine it throws errors all over the place!!!! this is why I hate PHP!!!!!" The simpler your rule set, the easier it is to teach and to remember, I would (and am) strongly argue that teaching the use of $array[index] in any context should not be done and that the use of {} to wrap variables is a far more robust system, but I cant stop you, I can only comment on why I think teaching its use is bad in any situation. I will not argue whether PHP is a good or a bad language to write websites in. It has its flaws(some which are quite major) but it has its positives to, like pretty much every programming language, I think its a great pick up and code language, kind of the VB of web languages :D
-
There is an easier way to do this. You should be able to write:
foreach ($Data as $d)
ECHO "{$d['recid']}{$d['name']}{$d['age']}";From the PHP Manual:
Quote:
Enclose the variable name in curly braces to explicitly specify the end of the name.
http://www.php.net/manual/en/language.types.string.php#language.types.string.parsing[^]
I had an opportunity to check this out, and of course, it worked. +5
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"As far as we know, our computer has never had an undetected error." - Weisert
"If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
-
[begin rant] So, I've been doing some integrations between our company Oracle E-Business Suite ERP and a website from a company that has been recently acquired by us. Our ERP exposes a webservice that our main website and the newly acquired company's website need to call, and sync clients, orders, products, etc (the two websites are e-commerce). So, I had to make a module for the new company website, and have that module call the ERP webservice with the needed data. The new company website is PHP. Now, I also had to output some data in some tables that would show up as a webpage full of logs, when I found a PHP bug (I guess it's a bug, cause if it's not, then it's elephanting plain weird). So let's say we have:
[outputting some unrelated table stuff]
[...]$result .= ''.date('d-m-Y g:i A', strtotime($header->getCreatedTimestamp())).'';
$result .= ''.(intval($header->getPlacedTimestamp() != 0)) ? 'Yes' : 'No' .''; // doing it directly screws everything up, this td and the one below are shown before the table
$result .= ''.(intval($header->getPlacedTimestamp() != 0)) ? $header->getPlacedTimestamp() : '-' .'';
$result .= ''.$header->getSupplierName().'';[outputting other unrelated table stuff]
[...]So, imagine my surprise when the result of the two ternaries gets placed BEFORE THE GODDAMNED TABLE!!! I mean, the output is:
[Ternaries result]
[table with my other data, no result from the two ternaries whatsoever, and the td's are simply missing]And the fix was simply to place the ternary result into two variables, and output those (I guess those two get somehow evaluated and executed before the other code, or I just don't know):
[outputting some unrelated table stuff]
[...]
$is_placed = (intval($header->getPlacedTimestamp() != 0)) ? 'Yes' : 'No';
$placed_ts = (intval($header->getPlacedTimestamp() != 0)) ? $header->getPlacedTimestamp() : '-';
$result .= ''.date('d-m-Y g:i A', strtotime($header->getCreatedTimestamp())).'';
$result .= ''. $is_placed .''; // doing this works, the tds are shown correctly, in their places
$result .= ''. $placed_ts .'';
$result .= ''.$header->getSupplierName().'';[outputting other unrelated table stuff]
[...]Oh, and I also had to output the HTML table from PHP code (as a requirement, I had to follow their...'guidelines', which enforce this :wtf: ) [end rant] Edit: Sorry, I just had to get this thing off my chest. I thin
-
BobJanova wrote:
Or you can use "... $s[recid] ... etc" (note no single quotes in the array indexer).
Don't omit quotes. php helpfully thinks a word without $ or quotes is a constant with the string value of the word. Until somebody defines the constant... Imagine you did $arr[version] instead of $arr['version']. It works until somebody define('version','3.1415927Beta'); Leif
-
BobJanova wrote:
Or you can use "... $s[recid] ... etc" (note no single quotes in the array indexer).
Don't omit quotes. php helpfully thinks a word without $ or quotes is a constant with the string value of the word. Until somebody defines the constant... Imagine you did $arr[version] instead of $arr['version']. It works until somebody define('version','3.1415927Beta'); Leif
