Talk:PHP/Archive 5

This is an archive of past discussions about PHP. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 1

←

Archive 3

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)

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)

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. — Preceding unsigned comment 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)

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)

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)

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)

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).

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).

That's not so much an official "name" as an extension that is sometimes used. Rob1n 21:57, 15 May 2007 (UTC)

Proposal for discussion for improvement of the PHP article

I propose that the article mention that recursive acronyms are retarded 64.221.248.17 17:51, 24 April 2007 (UTC)

I don't believe this would be the correct place to raise this issue. The article on recursive acronyms would probably be more appropriate, although you would probably have to rephrase the criticism, in order for it to be more encyclopedic. Jerazol 17:56, 24 April 2007 (UTC)

PHP Criticism

I am removing the part about the typing unpredictability. It is complete rubbish.

Eg:

$var = (int) function();

while always assign a integer value to "$var". Whether you feel this is a good implementation or not is a different argument and solely based on personal opinion or skill level.

Brad 12:32, 29 April 2007 (UTC)

I reverted your changes because they are still criticisms. You obviously don't agree with them and that's your deal (you seem to be a mission to defend PHP and cut as much criticism as you can based on your wording), but those criticisms do still exist. And for your example, it may always make $var an integer but that doesn't mean it can't cause problems (try returning an object from the function). It has nothing to do with agreement with interpretation, it can still cause problems. Cburnett 14:38, 29 April 2007 (UTC)

I ran a quick test and yes, trying to parse a object into a int does course problems, but this is a specific problem. If you do the following:

$var = (int) 0;

$var++; $var++;

if($var === (int) 2) { echo "Is an integer"; }

You will see that $var is definitely an integer. There can be complications in this approach and that may be a better vocal point for the typing situation in PHP but stating that the whole implementation is bad is miss leading. Brad 14:57, 29 April 2007 (UTC)

I don't have a better section to reply under but I also reverted your change of section name. Major revision changes is a term that refers to 4.x to 5.x changes. 4.0 to 4.1 is a minor change. Find another phrase that isn't ambiguous. Cburnett 14:43, 29 April 2007 (UTC)

Help me out then, because it sure as hell isn't a complete list of all the distros... I think Major covers this quite well, but that depends on your definition of the word. What would you rather see there? Brad 14:47, 29 April 2007 (UTC)

Ok, I didn't change it because I thought you might have something in mind. I would suggest something like "Significant releases" or "Significant releases history". Something other than major simply for its ambiguity. Cburnett 14:52, 29 April 2007 (UTC)

I have reverted the changes made to the criticisms section, as it does not at all improve on the article. The criticisms mentioned are valid, and even though some of them have been rectified in recent versions, a great many developers still use and rely on such features as register globals etc. Also, countering a criticism with what is going to be fixed in PHP6 is not valid imo, since PHP6 has not yet been released, and it's going to be even longer before everyone has transitioned to PHP6 from PHP4 and 5 Jerazol 16:00, 29 April 2007 (UTC)

To represent PHP as a static language is a misrepresentation. My way of structuring the criticisms allowed for the users to see which were based on development practices and which were based on language flaws itself. Also by Showing what the team has already dealt with allows new users to get a better understanding of what the status is. I never stated the PHP 6 fixes were a counter, that is purely there to inform the user. The changes make sense and should not have been reverted. Brad 07:26, 30 April 2007 (UTC)

First, wikipedia is not a tutorial so this article is not here to guide new users of PHP in any way. This article is not a "status" page, php.net can do that if they wish. Second, the individual points can spell out when they were dealt with but that doesn't erase the criticism. Now, converting some criticisms to "potential disadvantages" is not right since now you are comparing PHP to other languages. "Disadvantage" is by definition relative why "criticism" is absolute (it requires no comparison to exist).

STOP playing off criticisms as "potential disadvantages" and "coding style criticisms". I don't like your restructuring and apparently neither do others. I'm sure you having nothing but good intentions here but I see your changes as POV pushing simply because you are rewriting your own definition of what "criticism" means and downplaying people's criticism as something else. Cburnett 13:06, 30 April 2007 (UTC)

This part:

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.

A few points to consider:

PHP has always allowed === for strict type checking. So, what this means is types are not transparent to the programmer unless said programmer wants them to be.
"Some may consider this a feature..." more than some do because this behavior is intentional and utilized by many. And the word "may" should not be used here.
"...lacks full predictability." This is not true because PHP does not act randomly, everything has a reason and it's documented with many examples.

But I'm not sure how to reword this yet because some people do in fact criticize this feature but it's incorrectly worded in its current form. Any suggestions? Philipolson 01:02, 3 May 2007 (UTC)

Strict type checking with === nulls the benefit of weak typing. Perl has == and eq which lets you express the intent of what you want without requiring both variables to be the same type. IMO, PHP simplifies types and pointers too much which ends up complicating things when you know what you're doing. Perhaps the following?

Since PHP's types are dynamic and transparent, care must be taken to ensure proper usage. For example, '3.00' == '03' will yield TRUE but if the intention is to compare strings then using strcmp() should be used instead which would yield FALSE. Distinct operators like == and eq in perl allow the user to express intent while not requiring strict type equality as in with PHP's === operator.

I'm sure many URLs can be found that suggests perl's numeric & string operators but this URL suggests it and quotes some PHP 2 documentation. Cburnett 02:39, 3 May 2007 (UTC)

It's getting close, but not quite. I'd prefer not to mention perl so much (if at all), make === more prominent, and mentioning strcmp() does not feel necessary. Simply mentioning == vs === here seems appropriate as === covers all types and not just strings, and would work perfect in this example. What do you think about these thoughts? And be careful, since strcmp() does not return false that text could be misleading. Philipolson 01:26, 12 May 2007 (UTC)

More changes

In keeping current, default global variables and magic quotes have been switched off (default globals) and completely removed (magic quotes) in new versions. As such it is no longer of concern to the PHP community in general.

If someone wanted to start a security section for legacy then that may be a better place to put this, but at this time it does not belong in a criticism section.

I am removing these points.

Brad 12:32, 29 April 2007 (UTC)

As I said above, it is a long standing criticism of PHP and deserves to still be in the article. If you don't want it in the criticism section then you make a section about it. Cburnett 14:39, 29 April 2007 (UTC)

Very well, if you feel that it must be included (and I don't disagree, for histories sake) then I will place it in its own section. However it is misleading to claim it is still a problem when a lot of action to rectify the problem has been taken and all the major distributions have solved the somewhat large problem. Brad 14:43, 29 April 2007 (UTC)

What? It explicitly says the list is not applicable to current releases. "This list includes criticisms that have been rectified in recent versions." Furthermore, it says that 4.2.0 turned it off by default. If you read that and come away with the understanding that it applies to current releases then your reading comprehension skills are very lacking. Cburnett 14:47, 29 April 2007 (UTC)

Sorry, I got myself confused. register globals mentions when it was turned off but not magic quotes. I would certainly support elaborating on register globals with regards to historic use vs. current. Regardless, it is still a criticism. Cburnett 14:51, 29 April 2007 (UTC)

Sounds good to me. Brad 14:57, 29 April 2007 (UTC)

More changes being added

"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."

Is an argument that again does not seem like valid criticism. The fact that PHP does not require declaration is a feature, and not a bad one if you know about it. This is most likely written by someone not well versed in the use of dynamically declared variables, and as such has not relevance to the language itself. Whether this is a good implementation or not isn't discussed.

I am removing it.

Brad 12:31, 29 April 2007 (UTC)

What are you going on about? Just because it's a "feature" means that it can't be criticized? Give me a break! Cburnett 14:41, 29 April 2007 (UTC)

This is hardly a disadvantage to the language and unless it is further defined has no place in what is meant to be a factual document. Brad 14:59, 29 April 2007 (UTC)

Woah woah woah there, chief. "criticism" means "disadvantage" now? Double "give me a break"! Cburnett 01:21, 30 April 2007 (UTC)

The way the document is structured is way to miseading to new comer developers using this is a resource. Unless we break this up and explain that it is an opinion and what grounding parties have behind the statement. Brad 07:28, 30 April 2007 (UTC)

Criticism, by definition, means people's opinion. Cburnett 12:57, 30 April 2007 (UTC)

I will re-write that section to explain the different elements more carefully, but there must be some leverage to be able to say "This is only a problem for legacy applications" and classify it as such. Also the section currently presents coding preferences as absolute and without proper debate it makes it confusing for a reader. As stated previously, I will re-write this. Brad 13:39, 30 April 2007 (UTC)

Please use "legacy applications" carefully. I think it would be better to simply state what version it was changed and leave things alone that have yet to be published. Also, what do you mean about "coding preferences"? My point above is that criticism is criticism and it isn't your job (or anyone's) to qualify it. Cburnett 14:04, 30 April 2007 (UTC)

Formatting

I just made a change tot he objects section but I cannot get my code sample to format correctly. If someone could just try get that looking right I will write the rest of the article.Brad 08:09, 30 April 2007 (UTC)

Just prefix each line (even empty ones) with a space and it will be shown as preformatted text. Cburnett 14:05, 30 April 2007 (UTC)

Thanks Mate Brad 11:02, 1 May 2007 (UTC)

Just for reference

I made the changes from IP 138.130.75.164 to the objects section. —The preceding unsigned comment was added by Bradml (talk • contribs) 11:02, 1 May 2007 (UTC).

Constructor Over complicated

I believe the constructor example is over complex. I am going to just simplify it (unless there are objections, then I will but with an argument). Brad 11:22, 2 May 2007 (UTC)

I can see the encyclopedic value of adding basic syntax and limited examples, however I personally think the article is losing its encyclopedic value with the new code examples. -- I already forgot talk 12:05, 2 May 2007 (UTC)

AOL. This article should after all not be a tutorial. Jerazol 12:21, 2 May 2007 (UTC)

Agreed, A user put the constructor stuff in but it was not in any way useful for simply displaying how they work in PHP so I just thought a re-write would be a good idea. I think the Objects section is nice and beefy now. Let's move on... Brad 13:24, 2 May 2007 (UTC)

Zend stuff in "Object" section

The stuff about the behaviour of Zend Engine 2 in the Object section seems entirely out of place. Its level of technical detail is inappropriately high. I have never heard of Zend, and if it's to be mentioned its relevance to a general discussion of PHP needs to be set out first. This does look like someone with an axe to grind about a particular implementation who has slotted it in here because they haven't found somewhere better to make the point.

I haven't taken it out in case I'm wrong, but unless someone can explain why it's there, and preferably improve it, I'll assume it's OK to delete the paragraphs.

David Young Department of Informatics University of Sussex UK —The preceding unsigned comment was added by 213.162.107.11 (talk) 20:24, 2 May 2007 (UTC).

See Zend Technologies for who Zend is. The bit that the static part is getting at is what is called early static binding (as opposed to late static binding). Consider the following:

class a
{
  static function foo()
  {
    print __CLASS__;
  }
}

class b extends a
{}

Calling b::foo() will print 'a' not 'b'. That function is bound to the class 'a' at compile time, not run time. I think it should be rewritten not deleted. :) Cburnett 02:48, 3 May 2007 (UTC)

David, did you read the Histry section, because the Zend Definition is pretty clear there. However a section on it is desperately needed. Brad 12:35, 3 May 2007 (UTC)

OK, true, I didn't look at the history and didn't find out about Zend - I should have. (A minor point, by the way - the page is inconsistent between Zend 2 and Zend II). Anyway, I see the point, but I still think the discussions is too technical to place at this point, when someone who wants to find out about the general characteristics of PHP will be thrown off the scent. I can't rewrite it, but it would be very good if someone who understands this would address it.

David 213.162.107.11 14:52, 5 May 2007 (UTC)

Class Extendor section changed

You can't remove a valid, working example like that... Without it it becomes MORE complicated. I am changing back Brad 12:35, 3 May 2007 (UTC)

All the examples added to the OOP section is way over the top. If we were to be consistent with this, and add similar examples to illustrate every detail of PHP, this article would be unusable. I also removed again the example usage you had reverted, as this is redundant. The example should only serve as exactly that, an example of the syntax, not an explanation of how it is used. It is assumed that the reader is already familiar with the concept, and understands the example, or that he goes to the relevant article on WP to read up on it. Jerazol 12:53, 3 May 2007 (UTC)

The section was to help the user reading grasp the concept of what is being shown. Your reasoning for reducing the size of the Objects section is seriously flawed. Just because other sections aren't as in depth does not mean we would not present information to represent the capabilities of the language. I feel rather then making the article less useful we should try to actually get that FA rating by providing a plethora of valuable information in a structured and explanatory way. I don't feel that we should re-write the language documentation, I feel we should define the structure of it to the best of ability. Brad 13:15, 3 May 2007 (UTC)

The problem is, that you are writing a tutorial on the language, explaining how to use language features. That should not be the objective of the article. Jerazol 13:52, 3 May 2007 (UTC)

WP is not a tutorial. Instead of just showing how to do it, I'd like to see the sections enhanced by comparing & contrasted to other OOP languages. For example, my cursory page search didn't yield anything for "inheritance". PHP has only single inheritance unlike several other OOP languages. Nor does it have the "friend" concept like C++. It states in the lead sentence that PHP is reflective but this is never embellished upon in the objects section. I'm just listing things that can be added, compared, and contrasted, not complaining. Kudos to anyone who gets to this stuff before I do. :) Cburnett 14:42, 3 May 2007 (UTC)