Talk:PHP

From Wikipedia, the free encyclopedia

This is the talk page for discussing improvements to the PHP article.
This is not a forum for general discussion about the article's subject.
Article policies
Portal:Free software
 Free software Portal
This article is part of WikiProject Free Software, an effort to create, expand, organize, and improve free software-related articles.
??? This article has not yet received a rating on the assessment scale.
??? This article has not yet received an importance rating on the assessment scale.


Contents

[edit] Type Checking

PHP's type checking is very loose, potentially causing problems. Variable types in PHP, although they exist, are transparent to the programmer; though some may consider this a feature, as a variable can change from int to double and back again without extra lines of code.

My sense of this is that PHP is actually strongly typed with dynamic, transparent type conversion like Perl or AWK. If so, then the above statement could be better phrased. The type checking doesn't seem to be loose at all, because it detects int's versus double's and converts between them appropriately. The following phrasing may express the critcism better:

PHP's dynamic type conversion could potentially cause problems. Variable types in PHP, although they exist, are transparent to the programmer. Some may consider this a feature, as a variable can change from int to double and back again without extra lines of code. However, variable type errors are not detected at compile-time.

Brion.finlay 20:55, 26 December 2006 (UTC)

I think that if there is a section for criticism, there should be also a section for praise. Silvio Sisto, 2007-01-10 14:26:31 GMT -3

PHP's dynamic type conversion could potentially cause problems.

I think this could be further clarified to something along the lines of:

PHP's dynamic type conversion could potentially cause problems for those who are well versed in more strictly-typed languages.

I say this because, in my personal experience, I have been having to deal with the conversion from a loosely-typed language (PHP, in this case), to more strictly-typed languages (C, C++, etc). I'm having the same issue in reverse. AlexDeGruven 19:39, 29 January 2007 (UTC)

The fact that PHP implements transparent type conversion undermines the argument that it is indeed strongly typed. Even though data types are clearly defined, they are not checked at run time. Thus, floats can evaluate to bools, strings to ints, and so forth. In addition, PHP is not compiled, but is interpreted. I also think we should change the first sentence since being well-versed in a strictly typed language doesn't cause one to be unskilled with a loosely typed language. I propose the following:

PHP's dynamic type conversion could potentially cause problems for those who are not familiar with loosely typed languages. Variable types in PHP, although they exist, are transparent to the programmer. Some consider this a feature as values of one type are seamlessly coerced to another type as needed. However, since there is no type checking at run time, mistakes prevented by strictly typed languages can arise.

Pkrecker 06:16, 13 February 2007 (UTC)

It may be worth mentioning how PHP has both == and === with the latter being a strict type checking comparison. So in this sense, PHP offers both loose and strict type comparisons. But, of course the loose nature exists in many other ways like when adding a string to an integer. Philip Olson, 21:06, 01 March 2007 (UTC)

Pkrecker writes erroneously above that PHP is not compiled, however this is incorrect. Whilst PHP is not compiled to native machine code, it is compiled to machine code of a virtual machine, and the compilation of PHP gives similar advantages and opportunities to that of any other compiled language such as code caching, optimisation and increased security relative to the native source code form. Whilst some would say that the compiled form is interpreted by the virtual machine, the same can then be said of native machine code, particularly in architectures having a microcode interpreter running inside the processor and which in some cases be programmed itself through support for rewritable microcode. So PHP as of PHP 4 is compiled, and this is an important point. Moggie2002 12:09, 2 March 2007 (UTC)
So, if I understood you correctly, you are claiming that every programming language implementation, that has ever existed, is inherently interpreted, because the CPU might translate the produced machine code further? :)
PHP compiles source to bytecode in software, CPUs translate machine code to microcode in hardware — I would draw a very strict line here.
Another distinction that people often make is that "compiled" implementations are said to be ones where the compiler is manually invoked, and programs are distributed in compiled form, which includes Java, CLR, etc. While this is a more vague distinction, I think you'll agree with me that PHP doesn't qualify here either. Even the standard C implementation of Python, which transparently produces bytecode files whenever source files are imported, is not typically called a "compiled language" — though there is a bytecode compilation step which is more obvious than in the PHP4 implementation. -- intgr 13:26, 2 March 2007 (UTC)
Moggie2002's interpretation (ahem) of the term "compile" doesn't match that of modern computer science. JIT compilation is regarded as an optimisation technique for interpreters, not as actual compilation. PHP is clearly an interpreted language. Chris Cunningham 14:25, 2 March 2007 (UTC)
I'll try to clarify for you and explain in more detail why PHP is compiled. Firstly though and with regards to microcode and machine code interpretation, not all machine code is interpreted, but it can reasonably be said to be for some architectures when discussing the implementation of the processor. The microcode is a program running at a lower level than machine code, with its own instruction set, and interpreting the machine code instructions and controling the hardware accordingly. This is typical for CISC, EISC and other complex architectures. For some processors the microcode itself is writable in its entirety, and with processors such as David Harland's Rekursiv processor produced by Lynn (yes, the folks who make record players and hence the letter 'K'), the microcode may be a substantial feature. I was keen on microcode when first doing a PhD to explore my designs for object oriented CPU's for the efficient parallel execution of object oriented languages, but decided that non-microcode was the way to go if looking to pack potentially hundreds or thousands of CPU's into a machine as I was interested in. Others working on some similar ideas around the same time where MIT with their JellyBean machine.
Chris mentions JIT, however PHP does not have a JIT compiler in the usual sense of the acronym, and the Wikipedia article on JIT gives further details and clarity. PHP also lacks any source code interpretation ability, and even code fragments passed to eval() are compiled to bytecode first as that's the only way that code can be executed. JIT typically refers to the process of selectively translating bytecode into native machine code for enhanced performance, but this is not what is happening for PHP although it has been explored. Intgr makes the point about invoking the compiler manually with compiled systems, and actually this is precisely what's happening when you run PHP on a program. Certainly the compiled code is not saved in standard PHP, and this is not typical for compilers, but if you install a caching component then the bytecode is saved either to a file or shared memory, and when the same scripts are run again the precompiled code is processed and the source code is never parsed. This is one of the characteristics of compiled systems.
A trap is to consider PHP to be interpreted simply because a change to a script takes effect without any obvious explicit compilation. This behaviour does not define an interpreted system, and you will find automatic on the fly compilation behind the scenes with no manual invocation of a compiler in some C and C++ environments, and we would not then say that such systems are interpreted simply because a change to the source code had immediate effect.
The distinction between interpreted and compiled when discussing a language implementation really goes to how the source language is processed. Interpreted systems will parse the source code and execute directly from the parse tree. This is how PHP 3 was implemented, Ruby is the same last time I looked, and it's an easy and trivial way to get a new language up and running very quickly (the last language that I recently implemented this way was up and running in just a few hours). Compiled systems will translate the source code to a new language, typically lower level although not necessarily (e.g. Roadsend compiling PHP to Scheme before using a Scheme to C compiler and finally a C to native compiler), and it is the new language that is executed. This is exactly what happens in PHP, and it's why PHP is compiled.
With regards to the article, provided that there is wording to make it clear that PHP is compiled to bytecode and not native code, there should then be no misinterpretation (no pun intended!) with regards to the nature of the standard PHP implementation.
Moggie2002 03:30, 4 March 2007 (UTC)
"Firstly though and with regards to microcode and machine code interpretation"
Irrelevant, please spare your (and our) time.
"invoking the compiler manually with compiled systems, and actually this is precisely what's happening when you run PHP on a program"
The PHP4/PHP5 implementation compiles the code transparently, the programmer does not manually invoke the compiler.
"Certainly the compiled code is not saved in standard PHP, and this is not typical for compilers"
To the contrary, that is very usual for scripting languages.
"A trap is to consider PHP to be interpreted simply because a change to a script takes effect without any obvious explicit compilation."
My point was that implementations which do this are not generally considered to be "compiled languages", despite there being a transparent bytecode compilation step.
Anyway, question boils down to defining the terms, and I have yet to come across a strict definition for terms such as "compiled language", "interpreted language" and "scripting language" (ignoring the fact that this is not a quality of languages, so the terms are flawed in the first place; language implementations may or may not include compilation).
As far as I can tell, implementations where the compilation step is entirely transparent, are not called "compiled languages". But without clear definitions, there is no way of resolving this argument. So I think we should have a nice cup of tea and a sit down, and forget about this. -- intgr 06:35, 4 March 2007 (UTC)
I do agree that definition of terms is one of the areas where some people have stumbled on this issue. Compile or interpret is of course entirely implementation specific as it relates to, in this case, the Zend engine, and this is what the article briefly mentions. Furthermore we can legitimately say that the PHP bytecode is interpreted just as we can about other levels of processing (which is why microcode came up) as long as we're specific that this is what we are referring to. What is incontrovertible though is that at the implementation level, the Zend implementation of PHP is compiled, bringing with it the benefits that are associated with that approach. One of these of course is that with the addition of minor additional components, serialising and storing bytecode as pre-compiled files (similar to Java .class files) is possible, and the pre-compiled code can then be executed using a standard PHP engine and a small component to read back the compiled code. Such additions do not transform Zend PHP from an interpreted implementation to a compiled one, but they do turn it from one that compiles on the fly into one that reads pre-compiled files. Noting in the article that there is no separate compiler as standard and that PHP is compiled on the fly might clarify.
So to sum up. Zend PHP 4/5 is undeniably compiled rather than interpreted when we consider how the language is processed. It does lack a pre-compiler and cache as standard, which it is sometimes criticised for, and it compiles on the fly. This is all no big deal one way or the other, but we should try to be precise. With that put to bed, it's definitely time for a real cup of tea and a spot of JAM (with apologies for my deviation and repetition btw. :) )
Moggie2002 10:46, 4 March 2007 (UTC)

[edit] Safe Mode

I'd like a section about PHP Safe Mode

  • What is it?
  • Why/when is it used?
  • What could it do? (what type of scripts/actions would it prohibit?)

The PHP Manual says very short what it is and that it is only used because of lack of alternatives. A comment on the "Functions restricted/disabled by safe mode"-page says quite nice, why it is not working, and that generelly all file-handling and -management functions are restricted.

The Manual also says, that Safe Mode was removed in PHP 6.0.0. This should also be stated in the article?

Is anybody up for this?

(84.238.17.237 13:34, 28 December 2006 (UTC))

Did you look up the functions affected by safe mode at php.net?
I personally feel the addition of safe mode in the manner you suggest would be better suited for the wikibook than adding a section to this article.--I already forgot 15:55, 28 December 2006 (UTC)
The less talk about safe mode the better. This feature is being removed, and is not a core feature of PHP. Please do not add such a section here and use the manual instead. Philipolson 02:15, 3 March 2007 (UTC)

[edit] POV Section tag for Criticism

Did anyone else notice that other languages do not have a "criticism" entry at all, please remove this section and grind axes elsewhere. This is Wikipedia, not Truthiness. —The preceding unsigned comment was added by 72.183.117.43 (talk)

Adding valid and sourced criticism to Wikipedia is encouraged, see WP:POV. Many other language articles also include criticism:
For articles that don't yet include this section, you are welcome to add it, as long as it conforms to Wikipedia's policies. Also note that you should sign your comments on talk pages and add your comments to the bottom, not top, per talk page guidelines. -- intgr 07:38, 16 February 2007 (UTC)

Criticism in itself is pov and I'm not sure how such sections get started. For example: criticizing the type checking is pov as many programmers prefer PHP because of how it sets variable types. If a programmer has problems with type setting, its a personal problem and not a PHP problem. If the criticism is notable, it should be added but the section looks more like a nitpick.--I already forgot 16:09, 28 December 2006 (UTC)

All languages on Wikipedia should present notable strengths and weaknesses. At the time the criticism section was added to the article, the main text presented none of the commonly cited weaknesses of the language, neither current nor historical. The other way to present strengths and weaknesses is to properly intersperse them through out the article, but that requires careful editing to maintain a non-POVish balance. Personally, I like the criticism section as it is currently written. It could use more external citations, however. Also, this particular bullet:
PHP's dynamic type conversion could potentially cause problems. Variable types in PHP, although they exist, are transparent to the programmer. Some may consider this a feature, as a variable can change from int to double and back again without extra lines of code. However, variable type errors are not detected at compile-time, and the dynamic-typing behavior lacks full predictability.
is perhaps redundant, as the section already starts with the statement, Criticisms of PHP include those general criticisms ascribed to other scripting languages and dynamically typed languages. 209.92.136.131 18:27, 26 January 2007 (UTC)
What's often criticized in PHP is implicit conversions between variable types (a.k.a weak typing), not so much that it has dynamic typing. Python, for example, has dynamic, but strong typing, which means that variables have to be explicitly casted. Code such as this can produce not immediatelly obvious SQL injections:
if(0 < $input && $input <= 500) { mysql_query($db, "INSERT INTO table VALUES($input)"); }
-- intgr 20:15, 1 February 2007 (UTC)
Since both of the languages $input variables would have to be strings, that's not much of an argument. Failure to clean user supplied data would cause both languages to allow sql injection and type setting would do nothing to prevent it. Also, php allows type casting of variables so its up to the programmer to decide if they wish to set the type or not. This is a feature and not a critisism in my opinion.--I already forgot 08:07, 8 February 2007 (UTC)
Python raises TypeError when attempting to compare a string to an integer, it does not transparently convert between types (strong typing). Whether this is a feature or a pitfall is of course a matter of opinion, but I've seen people criticize implicit conversions and how PHP throws away the tail when converting strings to integers, or when arrays magically turn into a string saying "Array". -- intgr 10:10, 8 February 2007 (UTC)
"PHP does not enforce the declaration of variables prior to their use, and variables which have not been initialized can have operations (such as concatenation) performed on them; an operation on an uninitialized variable raises an E_NOTICE level error, but this is hidden by default."
In what sense is this a criticism? 129.78.208.4 00:50, 6 February 2007 (UTC)
I've been reading a ton of languages today, mainly their criticism (so lots of languages have criticism sections). The rest of the article is its "positive points", keep it. Its helpful established criticism of the language. StrangeWill 17:17, 12 March 2007 (UTC)
The criticism section used to be much worse. In general after reading the article the general idea was that PHP was a crappy and useless language, despite powering large amounts of the Internet including Wikipedia. I don't get that vibe anymore 76.108.49.253 02:40, 28 March 2007 (UTC)

Late in reply but anyway: most people don't really understand what NPOV really means. It doesn't mean a point-of-view cannot be represented. It means all POVs can be represented with no particular POV being placed as "the correct POV."

In other words, it would entirely be NPOV to add a section on what makes PHP useful but it would be against NPOV to remove the criticism section all-together. Cburnett 21:29, 28 March 2007 (UTC)

[edit] Move article

As I look around Wikipedia, all the articles on programming languages I see are in the following form: "Something (programming language)." Here are some examples:

I'm thinking the PHP should be moved to PHP (programming language). Any thoughts? Gutworth 03:50, 31 December 2006 (UTC)

The purpose of this is disambiguation. Python f.ex. is also a snake, Java is also an island, and a type of coffee, C... well, is the letter C. PHP does not have any other such things with similar name/abriviation of particluar noteworthyness. As you can see from PHP (disambiguation), the list consists of relatively low interest items. It makes sense then, to keep PHP where it is. Other examples of this is such things as XML, IBM, HTML etc. Jerazol 10:47, 31 December 2006 (UTC)

[edit] Language specification

Is PHP a standardized language with a full formal specification, or is it just defined by whatever the sole implementation happens to support at the moment? This information needs to be stated in the article, just as such info can be found in the articles for most other programming languages. Looking around on the official website, I can't find anything referring to a specification. Herorev 20:34, 1 January 2007 (UTC)

The PHP language is specified only by the PHP manual. The language is only developed by the PHP group and the manual is always updated accordingly. In fact, every PHP book I've seen always says that it is not meant to replace the PHP manual because it's so good.Gutworth 03:20, 2 January 2007 (UTC)

[edit] User 66.162.199.7

Can someone who knows how to do this get this clown blocked. This is the 6th time he's been vandalising this article in the last 2 days. Jerazol 23:12, 13 January 2007 (UTC)

[edit] mod_php, PHP as CGI ?

"mod_php" redirects here but doesn't appear in the current article. --anon :) —The preceding unsigned comment was added by 76.102.108.52 (talk) 19:47, 1 April 2007 (UTC).

[edit] PHTML

Since phtml redirects to php, perhaps some explanation somewhere about the name would be good? —The preceding unsigned comment was added by GavinTing (talk • contribs) 06:38, 8 April 2007 (UTC).

Retrieved from "http://en.wikipedia.org../../../p/h/p/Talk%7EPHP_2a95.html"