The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

I'd rather PHP not slip into the 'errors' of other languages. PHP is not an OOP language, it has the ability to perform OOP.

If you want to code in OOP, use Java, C++ or something other than PHP.

However, going back on topic. I'd love to see more 'live' server functions (ASP influences I guess). Once PHP can perform things without the assistance of Ajax, there would be no doubt PHP would become the widest used language.

OOP is a great language, I only know the basic and ideas of OOP and they are great, it really makes php more efficient but not necessarily easier to code.I think it would be great if PHP 6 brings more elaborations and new ideas such as the OOP language.

PHP isn't an "elegant" language, the functions are organized in an inconsistent way, it is not very OOP. It's obviously a language that grew over time rather than something that has been designed with a clear vision.

BUT... it's reliable, flexible, easy to learn and concise, and the vast choice of extensions allow it to do pretty much everything, often with a just a few lines of code.

I think a good language is one that gets the job done and PHP is pretty darn good at that. Those who want something more elegant have a lot of choice: Python/Ruby/Java etc.

OOP is a great language, I only know the basic and ideas of OOP and they are great, it really makes php more efficient but not necessarily easier to code.I think it would be great if PHP 6 brings more elaborations and new ideas such as the OOP language.

OOP is not a language... it's an acronym.

Creativity knows no other restraint than the
confines of a small mind. - MeGeekly Humor
Oh baby! Check out the design patterns on that framework!

I'd rather PHP not slip into the 'errors' of other languages. PHP is not an OOP language, it has the ability to perform OOP.

If you want to code in OOP, use Java, C++ or something other than PHP.

However, going back on topic. I'd love to see more 'live' server functions (ASP influences I guess). Once PHP can perform things without the assistance of Ajax, there would be no doubt PHP would become the widest used language.

According to netcraft PHP is already the most popular server side language.

Creativity knows no other restraint than the
confines of a small mind. - MeGeekly Humor
Oh baby! Check out the design patterns on that framework!

When PHP 6 comes out I really only want one thing. Admittedly it's a major thing, but I believe it would help the language out a hell of a lot. That one thing - place all existing functions in a legacy namespace and then rebuild the function library with consistently named functions in an object oriented fashion.

The existing functions would still be around - they just would have to be imported and for backwards compatibility a flag would be placed in the php.ini file that would do this automatically. It could even ship with the value set to true.

But if it's set to false the scatterbrained php function library goes away replaced with one planned out from the start and itself divided into namespaces.

So this weird situation of string functions sometimes having underscores and sometimes not -- strpos, strchr, str_replace, str_split; or not even referencing strings in the name; explode and implode; goes away. Instead.

PHP Code:

$a = "The quickbrown fox jumped over the lazy dog";

$a->position('dog'); // Find the position of dog in $a
$b = $a->explode(' '); // Explode $a into an array and return it to $b.
$a->explode(' '); // As above, but since there is no var to assign it to $a will become an array and hold the result of the explode.

$a->shuffle(); // Shuffle the order of the elements..

And so on. Functions could also be rewritten to throw exceptions for exceptional circumstances, not merely return false as many do right now.

You can wish, but not all wishes come true ^_^. If you want those features that badly, fork PHP and make it your own like PolarScript

Creativity knows no other restraint than the
confines of a small mind. - MeGeekly Humor
Oh baby! Check out the design patterns on that framework!

I agree with the proposed ideas - and having the legacy namespace automatically imported in due to a php.ini setting is an ingenious idea!

I think it's about time PHP was forked out into two languages, to be fair. Sure, I'd use another language - if there was one with any where NEAR the web development capabilities of PHP - but there aren't.

One branch would be for those who get to a certain point and decide that they want better library organisation, the other for those who want to stay with classic PHP. Both would have their strengths and weaknesses, but we can't keep trying to add features to a language designed to be simple - instead, branch into a sublanguage which is designed to be powerful.

Jake Arkinstall
"Sometimes you don't need to reinvent the wheel;
Sometimes its enough to make that wheel more rounded"-Molona

... but we can't keep trying to add features to a language designed to be simple - instead, branch into a sublanguage which is designed to be powerful.

So you are saying that PHP is simple but not powerful? What utter drivel!

PHP is the #1 language for web development because it is the best language for the job, and NOT because it is technically pure. Besids, no-one can define what "pure" actually means.

For those of you who say that PHP should be forked I say "fork off".

For those of you who say that "PHP is not a proper OO language" I say that if you cannot write software with the OO capabilities that were in PHP 4 then you are a lousy programmer. I wrote an entire ERP application using PHP and it still runs brilliantly, even under PHP 5. Why did I do it? Beacuse I can! If you can't then you are a lousy programmer.

For those of you who say that the inconsistencies in the PHP libraries are "a problem" I would point out that every language has its inconsistencies, but if you use a proper IDE it will provide hints when you start typing in a function name, and then it will show you what the arguments are. If you can't handle this then you are a lousy programmer.

For those of you who say that PHP should be statically typed I say stop using PHP and switch to a language which is more in line with your mental capabilities.

For those of you who say that everything in PHP should be treated as an object I say "phooey". Everything is, in fact, a string. The most common use of PHP is to write web applications using HTML forms and SQL databases, and - guess what - the input from an HTML form is always a string, and when communicating with an sql database it is always done with a query statement which is a string.

In short, for those of you who say that PHP is deficient I say that it is YOU who are deficient. If you like the features of those other languages so much then stick to those other languages. PHP became the #1 language without your support, so your opinions are not worth the toilet paper on which they are written.

So you are saying that PHP is simple but not powerful? What utter drivel!

PHP is the #1 language for web development because it is the best language for the job, and NOT because it is technically pure. Besids, no-one can define what "pure" actually means.

For those of you who say that PHP should be forked I say "fork off".

For those of you who say that "PHP is not a proper OO language" I say that if you cannot write software with the OO capabilities that were in PHP 4 then you are a lousy programmer. I wrote an entire ERP application using PHP and it still runs brilliantly, even under PHP 5. Why did I do it? Beacuse I can! If you can't then you are a lousy programmer.

For those of you who say that the inconsistencies in the PHP libraries are "a problem" I would point out that every language has its inconsistencies, but if you use a proper IDE it will provide hints when you start typing in a function name, and then it will show you what the arguments are. If you can't handle this then you are a lousy programmer.

For those of you who say that PHP should be statically typed I say stop using PHP and switch to a language which is more in line with your mental capabilities.

For those of you who say that everything in PHP should be treated as an object I say "phooey". Everything is, in fact, a string. The most common use of PHP is to write web applications using HTML forms and SQL databases, and - guess what - the input from an HTML form is always a string, and when communicating with an sql database it is always done with a query statement which is a string.

In short, for those of you who say that PHP is deficient I say that it is YOU who are deficient. If you like the features of those other languages so much then stick to those other languages. PHP became the #1 language without your support, so your opinions are not worth the toilet paper on which they are written.

That's just my humble opinion, of course.

Yeah... That's polite and conductive. So, shall we follow your implied decision and close all development on this perfect language? PHP 5.3 forever hur hur hur....

PHP is a wonderful language. It has put food on my table for 5 years. But it isn't without it's flaws. I want to see the language move forward, embracing its strengths while removing those flaws.

If attitudes such as yours won the day PHP would still be in version 3. They are not productive. Telling people to make forks is not productive either. I would like this thread to return to a more constructive conversation about what can and cannot be done with the language.

So I'm going to break this down into points.

The Legacy Namespace.
Inconsistent function names and argument orders are PHP's largest remaining flaw. They are the result of a language that was grown rather than planned. The incorporation of a namespacing schema as of PHP 5.3 however presents us with a wonderful opportunity to reorganize the functions of PHP while preserving backwards compatibility in one fell swoop.

This is the point of the legacy namespace suggestion. Whether the functions in other namespaces are object oriented or not is emphatically not the point. Indeed, because of how namespaces work you can have both.

Datatypes are also a seperate issue entirely. I'll address them later in the post, but for the moment consider the power of namespacing out the functions. Scripts would run faster if they didn't have to load up pointers for all, what is it now, 3000 inbuilt PHP functions? Names could be cleaned. Where multiple functions exist for the same task a common name can be chosen.

The activation of the legacy namespace would be a PHP.ini setting. For PHP 6 the legacy namespaces would be enabled by default. This means newly upgraded systems should behave normally. From either PHP.ini or .htaccess the legacy namespace can be removed. Looking forward, PHP 7 would ship with legacy namespaces turned off by default, and only by PHP 8 some 10 to 16 years from now would the legacy functions be removed from the language just as register_globals and magic_quotes go bye bye in PHP 6.

The point of the change is to make one of the easiest server scripting languages out there even EASIER to learn. Consistency is very helpful for beginners.

Datatypes - Scalar, Tolerant and Strict
In PHP all variables are scalars. The engine chooses the datatype best suited to store the information at hand and evaluates the variable in the context of that variable.

Now you can cast a variable to a certain value with intval, floatval, strval and so on, but your result is STILL A SCALAR. Hell, the bloody $ mark on the variables is supposed to be a reminder that the variables are all scalars.

And honestly, for learning purposes and 90&#37; of what we do with PHP this is fine. But what about the other 10%. The question I ask is can the language be retooled to allow for other datatype handling in parallel to the current loose handling the language does now. I think it can. The idea is the tolerant and strict variables.

Strict variables are strictly typed. They require a new keyword - strict - to be introduced to the language.

The strict variable gives the people who want or need a variable's type to be invariant that option. If you don't like that behavior, don't use it. Comparisons between variables are still loose - the === doesn't go away.

Tolerant variables require the tolerant keyword to be added. Like the strict variables you declare their datatype when they are declared. Unlike strict variables putting the wrong type of data into a tolerant variable only raises an E_NOTICE, then the engine silently converts.

Functions change by being allowed to have their arguments be tolerant or strict. Tolerant and strict functions can be overloaded, a very powerful advanced programming tool.

In the very simple example above floats are multipled and integers added. Not a very useful behavior difference - but when the function is called the datatypes of the variables determine which function is used.

Now a Radical suggestion -- . to #, . to replace the \ -> :: nonsense
A longstanding problem that really reared it's head in PHP 5.3 was namespace incorporation and the weird :: operator's nuances finally coming in to bite PHP's dev crew in the ***. As an interim solution they went with \ as a scope operator for namespaces.

Every other language in the C family uses . for scope resolution. Whether the object is instatiated or doesn't matter. Now -> and :: are a long standing part of PHP and not to be taken lightly, but is it possible to put . to it's normal use?

Biggest disadvantage - scripts written for one syntax will NOT work when the other is around. Second PHP's use of . is valid, I don't know how many times Javascript's inexact string addition with + has given me fits but it's many.

However, PHP currently uses # for Perl style comments. Does PHP really need it in that role? I don't think so - C style comments are predominate.

So my proposal, and this is the most radical of the group, is to add a PHP.ini setting that changes the scope resolution mode. As I make this suggestion I fully realize it might be flat out impossible to do. But if it's possible then # becomes the operator to add strings.

If this can be done the more familiar dot syntax can be used for scope resolution. This makes PHP easier to pick up for programmers of other languages and beginners will certainly find one scope operator easier to grasp than 3.

The grab bag
These are the smaller suggestions

Override
Override is a keyword in many languages that marks a method as overriding a method of a parent. It's use would be optional, but if used the parent class must have a method to override or a E_USER_ERROR is raised.

Make all errors catchable
Make all errors catchable, even parses and fatals (assuming the engine was able to parse the code that defines the handler).

Object Oriented function library
Namespacing given above allows object oriented functions to exist alongside object oriented ones, but if I had to choose I'd go for the object oriented approach.

Scalars have all primitive methods attached. So
$a = 'This is a string';
$a->shuffle();

Shuffle is an array function. Scalar strings are arrays where each letter is an element, so calling shuffle on it shuffles the letters. With scalars warnings only are thrown when no conversion is possible. Tolerant and strict vars only allow the methods that apply to their values to be called in this manner.

Public, private, protected in namespaces
Functions and variables within a namespace can be public, protected or private. Further classes within a namespace can be public, protected or private to the scope of the namespace.

Prototyping
PHP has the potential to allow object prototyping as Javascript does since both are interpreted languages (Prototyping is impossible in compiled languages as far as I know). Prototypical inheritance is extremely powerful, but it also an extremely big can of works.

Yeah... That's polite and conductive. So, shall we follow your implied decision and close all development on this perfect language? PHP 5.3 forever hur hur hur....

I am not suggesting that all development on PHP be stopped because it is already a perfect language (it is not, but neither is any other language), but that certain changes requested by certain individuals be totally ignored. The changes I am talking about are alongthe lines of "I like language X, so I'd like PHP to be just like language X". If you like language X so much then stick with it and leave PHP alone. PHP got where it is today because it is different from language X (and Y and Z). If you can't live with those differences then don't use the language, and please don't pox it up for the rest of us.

The beauty of PHP is that it is a simple yet powerful language which does not impose any particular style on the programmer. Thus I can write code which is either procedural or OO - the choice is mine. I can use namespaces or not - the choice is mine. I can use interfaces or not - the choice is mine. I can use exceptions or not - the choice is mine.

Provided that any new features which are added to the language do not pox it up for the rest of us then add them to your heart's content. But do NOT try to force me to use them.

Provided that any new features which are added to the language do not pox it up for the rest of us then add them to your heart's content. But do NOT try to force me to use them.

There comes a point when deprecations need to be followed through on to keep the underlying engine code sane and working smoothly. With PHP 6 magic quotes and register globals go away - too terrible practices that shouldn't have been added to begin with.

I disagree that the language needs to allow everything. It's focus should be on its strength - it's easy to learn. Part of that is having certain behaviors and patterns be optional. But part of that is going to need to be changing some behaviors to be consistent. Error vs. Exception handling for example. Having both confuses everyone. The language currently has two file handling approaches - the clumsy file-open, file-read, file-close circus and file_get_contents / file_put_contents. Rethinking this out and implementing something that is sound and easy to learn and teach would be invaluable.

Legacy namespaces is a bridge to allow old code to work and facilitate the transition. The incoming new namespaces should become the standard so that, eventually, the legacy namespaces can go away.

Saying concepts from other languages should be avoided because PHP isn't those other languages is a red herring in any event - PHP owes it's very existence to other languages.

I'm sure you meant "two" and not "too". In hindsight these two were a bad idea, but they seemed a good idea at the time. As virtually all experienced programmers already avoid them like the plague their passing will not be missed.

Originally Posted by Michael Morris

Error vs. Exception handling for example. Having both confuses everyone.

I'm not confused at all. I can do everything I need with the error handler, and I see absolutely no advantage in switching to exceptions.

Originally Posted by Michael Morris

The language currently has two file handling approaches - the clumsy file-open, file-read, file-close circus and file_get_contents / file_put_contents.

So what? Two approaches are actually necessary - one reads the file in chunks while the other reads the whole lot in one hit. Take one of those options away and you'll have a lot of angry programmers after your blood.

Originally Posted by Michael Morris

Legacy namespaces is a bridge to allow old code to work and facilitate the transition. The incoming new namespaces should become the standard so that, eventually, the legacy namespaces can go away.

I do not see what all the fuss is with namespaces. I have programmed for 35 years without them, and I do no see what advantages they bring. My code does not use namespaces, and I don't see why I should change it just to satisfy you.

Originally Posted by Michael Morris

Saying concepts from other languages should be avoided because PHP isn't those other languages is a red herring

I did not say that PHP should never be improved and enhanced, I just object to demands that PHP should be "just like language X" simply because some poor programmers do not have the mental capacity to deal with the fact that PHP is different from language X for very good reasons. If PHP was exactly the same as language X then one of them would be redundant. PHP is a VERY popular language because it is different - it is simple for novices to learn yet powerful enough to satisfy the more experienced programmers. I suggest you learn to live with those differences and stop trying to make PHP a clone of other languages.

I just object to demands that PHP should be "just like language X" simply because some poor programmers do not have the mental capacity to deal with the fact that PHP is different from language X ...

Enough is enough. Such downtalking doesn't prove you're smart - it just proves you're very insecure about your intelligence and feel the need to try to prop it up by insulting others. If you aren't smart enough to comprehend what a namespace is and why they exist in pretty much every language out there that isn't my problem. Welcome to the killfile.

If you aren't smart enough to comprehend what a namespace is and why they exist in pretty much every language out there that isn't my problem. Welcome to the killfile.

I have been programming for over 35 years with a number of different languages, and none of them had namespaces, so your assertion that "they exist in pretty much every language out there" simply does not hold water. Namespaces are a recent addition to PHP, but they are an OPTION, not a REQUIREMENT. I choose not to use them for the simple reason that the cost of changing my code is far greater than any benefits generated, so it would be a pointless and costly exercise.