Talk:PHP/Archive 4

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

Archive 6

→

Archive 8

Addition of important aspects to PHP

I have added some info in things I saw missing in the article, specifically PEAR, PECL, and Smarty, among others. I also think a list of databases supported should be added. I haven't fleshed out the paragraphs, so feel free to add to my changes. I really just wanted to get them into the article and flesh out a format for the article as a whole. I am also thinking of moving the PHP 6 to the History section, but then talking about future releases in the history section is a bit odd. Maybe we can add a section called Version History, or Releases separate from the history dealing with development. Bytebear 20:06, 29 September 2006 (UTC)

Variable evaluation in string context

There's quite a lot more to what is, and isn't evaluated in string context than wether you use single or double quotes. For instance, assoc arrays, you shouldn't quote the key, or else you get a syntax error, complex variables like objects, you need to use special syntax with {} etc etc. Personally I think the original text was adequate, as we do not want to enumerate all possibilities, and it's not as simple as that variables are evaluated within double qoutes or heredoc. Besides, the most recent addition, is imo wrong. It's not the variables value that is embedded, but the variable itself. True, this *evaluates* to the variables value, but that is not the same thing. Jerazol 18:57, 9 October 2006 (UTC)

I'm fine with further rewriting, but the original text is a) unreadable for people who aren't computer scientists and b) so vague as to be nearly pointless. If one is going to bother mentioning that PHP allows variables to be evaluated within things which are ostensibly strings sometimes it should be reasonably clear what these circumstances are. I'd rather be slightly inaccurate than useless; this is the approach favoured by most non-expert textbooks. Chris Cunningham 23:38, 9 October 2006 (UTC)

I unfortunately have to disagree. Standard coding practice in PHP is to quote associative array keys. In addition, variables in the current version of PHP can legally be parsed within double quoted associative keys without error. The use of curly braces ({}) is not a requirement when assigning variables (or specific to an object string) and is most often used to separate string data with no white space such as "1110011{$bin_digits}00110101". Though the subject on double quoted strings can be expanded to cover such uses and the additional escape sequences, the simple difference between double and single quoted strings as used in the article remains the same. I also don’t understand the statement of "It's not the variables value that is embedded, but the variable itself. True, this *evaluates* to the variables value, but that is not the same thing." The variable (in the string) isn’t evaluated but is parsed and compiled into the assigned variable at run time depending if the string is wrapped in single or double quotes. The variable name in the string code has no function other than being parsed and added to the new string either as the variables assigned value (“”) or as the variable name (‘’) so I don’t understand how stating the value is embedded when using double quotes is wrong. Maybe the wording needs clarification?

My intention was not to confuse or make a statement but to add additional information that could be expanded on as a compromise to the addition, deletion, and the subsequent re-addition by other users. If anyone wants to rv the change or expand/rewrite the entry, I have no plans of getting into an edit war over it so feel free to do so. It was just a quick and dirty compromise entry.--I already forgot 11:23, 10 October 2006 (UTC)

It's no big deal, and I see I'm in minority here, so I guess we'll just leave it as it is :-). To clarify what I meant about assoc arrays, is that the code <?php $foo['asdf'] = 'asdf'; echo "The var $foo['asdf'] asdas"; ?> will give you an parse error. You need to leave out the single qoutes, ie. echo "The var $foo[asdf] asdas"; The same goes for objects and other complex variables. It's often not as simple as saying that within double quotes you can embed variables. Jerazol 16:38, 10 October 2006 (UTC)

Got it, thanks for the clarification. --I already forgot 01:59, 11 October 2006 (UTC)

Omitting quotes on string array keys is often seen in novice code, but this means access by a constant and is compiled as such. When the constant is, most likely and one would hope, not found at runtime, the execution engine converts the constant to a string and issues a notice level warning to that effect. For example:

Notice: Use of undefined constant asdf - assumed 'asdf'

would result. Whilst it is true that string indices will give an error in the example mentioned, this is resolved simply with the addition of braces, and that method should be used and never omitting the quotes. e.g.

echo "The var ${foo['asdf']} asdas";

Moggie2002 23:28, 20 November 2006 (UTC)

That is incorrect. Where do you get the information that this method is prefered over leaving out the quotes? If this is documented in the manual, or some sort of best practice guide, I'll be happy to accept that, but the claim that writing <?php echo "asdasd $foo[key] fasfa"; ?> will raise a notice error, is false. Personally, I do not use either method, but that does not negate the fact that they're both perfectly valid syntaxes. Jerazol 04:50, 21 November 2006 (UTC)

Indeed, you are correct and I am wrong. Thank you for catching that. However, this only makes it even worse to omit the quotes as those learning by example may believe that it is acceptable to do the same outside of a string context. I do respect your right to disagree on that point. Presumably we are in agreement, however, that a notice level error would be generated if one were to write

echo $foo[asdf];

if the constant asdf did not exist. Unfortunately, this is not an uncommon mistake to see. The problems here being that there is a performance hit while the zend_error() mechanism is invoked, that were an end user to have notice level errors displayed then error messages would be generated being at best a nuisance and in the worst case rendering a script unusable, and that if the constant asdf did happen to exist then unexpected behaviour is the likely outcome. So we have the following. $foo[asdf] is semantically different to "$foo[asdf]". $foo['asdf'] is equivalent to "$foo[asdf]", "${foo['asdf']}" or "{$foo['asdf']}". The use of braces to delimit variable names has precedent in other languages, and is consistent and should not confuse. $foo[asdf] having a different meaning to "$foo[asdf]" is an inconsistency that once seen, may give rise to confusion and incorrect use that could lead to errors that may only happen at runtime, and without thorough testing, could go undetected indefinitely. Using braces gives the benefit of consistency by offering the same variable syntax as would be used outside of a string, and on balance is preferable to a form that means something different outside of a string and may give rise to programming errors. Thanks again for pointing out (yet another) language inconsistency. Moggie2002 10:56, 21 November 2006 (UTC)

Yes, and this was kind of the point I was making. That expanding on this section of the article, was pointless, and, that it would be better to leave it up to some tutorial or book, to explain the finer points of variable evaluation within string context. I was in no way advocating that this piece of information should be included in the article, only illustrating that it's better to keep this section short, rather than ellaborate and inacurate.Jerazol 12:18, 21 November 2006 (UTC)

Agreed, and not only that, you could simply chop it out altogether as it's not necessary within the context of getting a basic understanding of what PHP is about, and it would not affect whether after reading the article someone wanted to learn more. There are other problems with that para too, as the text

and a type does not need to be specified in advance.  

is inaccurate as a type cannot be specified in advance. It's fair enough to mention that the language has variables because not all languages do, but saying that plus a comment about types is probably enough. I added the point that variables are case sensitive to draw attention to an inconsistency between variable names and functions/classes, but even that could go. Another inconsistency that I don't think is mentioned is that the associativity of ?: is 'wrong' in the sense that it's the opposite of how BCPL, C and others define it, although that's obviously not an issue if you use parentheses. I'll be interested to read the history of changes overall in another months time :) Moggie2002 14:16, 21 November 2006 (UTC)

Strictly speaking it's neither the variable's value nor the variable itself, but a reference to the variable. Perhaps the writer perhaps had in mind what they thought happens at runtime, but then it would still not be quite correct. A line such as

echo "High Score $score!";

thanks to tokenisation in the parser is compiled as if the source were

echo "Hi" . " " . "Score" . " " . $score . "!";

Double quoted strings are not processed using variable expansion and text replacement, and so there is never any embedding of values that one might imagine happens. As an aside, the inefficiency of the above, which generates bytecode string concatenation instructions for each word and whitespace portion plus the code for variable access, is one of the notable "optimisation for size" opportunities at runtime. Moggie2002 00:07, 21 November 2006 (UTC)

PHP 1&2

There is no info here about why PHP 1 & 2 wasn't released? Or was it, but is there no info on that subject jet? Could someone clarify it, or add it? Jaapvstr 09:47, 13 October 2006 (UTC)

Everything before the PHP 3 section deals with PHP/FI 1 and 2. Chris Cunningham 12:50, 13 October 2006 (UTC)

Bolding letters to expand initialisms

Is there a good reason to make the initial letters bold in expanding initialisms? The manual of style discourages this, and I think it's insulting to the reader. Unless there's a special reason to be doing it here, I'd like to go through and clean these up. —ptk✰fgs 09:34, 19 October 2006 (UTC)

Go for it. Chris Cunningham 10:04, 19 October 2006 (UTC)

linkspam?

as far as the Zend link goes. --68.210.96.31 17:09, 22 October 2006 (UTC)

I don't see any problem. —ptk✰fgs 18:51, 22 October 2006 (UTC)

Magic quotes section

The magic quotes section is too brief to be useful. At least, I couldn't make any sense of it, and I can program fairly well and understood the rest of the article. Could someone expand it a little please?

I don't see why we need to have a separate section about configuration. This is covered in the PHP-manual, and I don't see the point of highlighting a feature like magic quotes, which are depracated, and will no longer be available from version PHP6. Jerazol 16:46, 24 October 2006 (UTC)

PHP and XHTML

I know this isn't the place to ask this, but I had a friend telling me PHP won't work within XHTML 1.1 (application/xhtml+xml). Is this true, or was he being dumb? Or do hosts need to change something in php.ini or in apache configuration to allow it to work? Or do I need to use the XML functions of PHP in order to work with XHTML?

Maybe the answer to this question(s) might be useful to add to the article. At least, I know it will be useful to me :) --Saoshyant ^{talk / contribs} (I don't like Wikipedophiles) 21:38, 6 November 2006 (UTC)

Basically, he was talking nonsense. PHP as such, is independent of the output produced, and there's no reason why you shouldn't be able to produce valid XHTML with PHP. As for the content-type used when serving pages produced with PHP, that's an issue for the webserver to decide. It is off course also possible to set custom content-type header using the PHP-function header()

Actually the problem your friend was referring is that PHP with XHTML output NORMALLY is interpreted as PHP by most browsers. Just IE accept it as XHTML because it is a [censored] [censored] and accept non-standard (including non-standard XHTMLs). IE can even EXECUTE GIF files as VB scripts!. The problem is the file name will continue to be "filename.php", and because of that the server will send a header informing it is PHP. However, PHP HAVE a function to send headers. This simple command will make it work: header("Content-type: application/xhtml+xml;"); So the solution is to just send a header informing it as XHTML. Another solution is to make the web server recognize the PHP output as XHTML, wich is more complicated. So the problem isn't from PHP, is of your friend who dont know how a content type authentication work in browsers. Sspecter 03:27, 25 November 2006 (UTC)

It surely took a while to get an answer, but that's okay because the clarification was exactly what I wanted to know. Thanks a lot, you two.--Saoshyant ^{talk / contribs} (I don't like Wikipedophiles) 16:02, 21 December 2006 (UTC)

Popularity contest

PHP competes with Visual Basic and C++ as the third most popular programming language behind Java and C, based on world wide availability of practitioners, courses and vendors [1].

Very impressive sounding, but the "TIOBE index" is basically a glorified Google hit test, and assuming the number of search engine results is really a reliable indicator of the "availability of practitioners and vendors" is fallacious and delusory. — Miles (Talk) 02:35, 17 November 2006 (UTC)

I dont know if this will help anything, but: http://www.php.net/usage.php GeorgeMoney (talk) 04:21, 21 November 2006 (UTC)

Criticism

Under Criticism it says: "Many PHP programmers output the data directly into HTML pages without first encoding the data string as HTML. This leads to Cross-site scripting security holes appearing frequently in PHP applications." For me that sound more like criticism to PHP programmers, not PHP itself. I'm not sure. Should it be deleted? 85.225.112.160 16:49, 25 November 2006 (UTC)

While I agree planned features don't need to be added, and it does say on the list of criticisms that some of them have been resolved, I think it's worthwhile to address which have been resolved. For example the register globals thing is a total non-issue for people running recent versions of php. This is an important fact! Then again, are corrected flaws even worth mentioning? Say there was a remote shell exploit in version 2. That would have certainly been a bit deal at the time -- but is it still relevant? 69.174.135.178 12:56, 1 December 2006 (UTC)

People that read the page probably don't expect it to read like a list of updates; this is what we have php.net for. So if register_globals or some other issue is resolved then it's a non-issue that need not be mentioned. However register_globals and some of the more notable design faults, flaws, security holes and release goofs that have plagued PHP over the years perhaps are worthy of mention in a section within the context of its historical development to show that it's not been plain sailing for users of PHP. Moggie2002 15:13, 1 December 2006 (UTC)