Page 1 of 2

2 PHP Versions: Classic and Pro

Posted: Fri Apr 28, 2006 8:00 pm
by Ollie Saunders
I've been toying with the idea of making a separate version of PHP. PHP is great, everybody on this forum should know that but for those who use it day in day out there are frustrating aspects to it that could be improved on in an isolated environment.

PHP 5 was a bold step that I have come to appreciate but it has inadvertently created two strains of PHP developer. Those who have the ability to configure their own server and install PHP 5 and those that don't and are stuck with PHP 4. So it would seem that this separate version idea already exists in some disorganised unintentional sense; why not capitalize on it and benefit both parties?

Let's consider for a moment what causes so many good language feature suggestions to be declined. Well for starters the developers of PHP are massively focused on PHP's ease of use. It is this belief that led to the creation of 'register globals' *insert groan* and the rejection of features which impose some much needed structure to PHP. Secondly PHP's maturity is heavily restricted by backwards compatibility concerns.

Suppose PHP was to be separated out into two versions what would those versions be? I envisage PHP Classic and PHP Pro. PHP Classic would be the PHP 4 you know and love while PHP Pro would be like PHP Classic with:
  • Case sensitive functions
  • Properly standardized functionNames(), arguments and return types
  • Cleaner global namespace
  • Fewer PHP.ini configurations in favour of new special runtime configuration syntax
  • Built-in Optimizer
  • Out dated function sets replaced with more comprehensive classes
  • Bundled with Zend Framework
  • Manatory OO based development (maybe objective input and output streams for example)
  • Block level variable scope
  • Drop double-quote string syntax?
  • Drop variable dollar symbol syntax?
The last two represent the kind of radical change you would be free to make to improve the language that would never otherwise be possible. I'm sure you can think of plenty more.

Separating PHP out into two versions would also have psycological implications. For example there would be forums for PHP Classic and forums for PHP Pro and a good deal of the users of these forums would stay on one of the other and created separate environments.

Anyway that's my piece. I'm not saying this is a good idea but I'm interested in peoples opinions on this and also people would like to see put into PHP to aid more serious developers.

Now spout!

Posted: Fri Apr 28, 2006 9:40 pm
by Christopher
Darn! Someone already thought of that here.

Posted: Sat Apr 29, 2006 3:09 am
by Ollie Saunders
is that php?

Posted: Sat Apr 29, 2006 3:50 am
by Chris Corbyn
ole wrote:is that php?
No its ruby :? I'm confused too. What are you referring to arborint? :)

Re: 2 PHP Versions: Classic and Pro

Posted: Sat Apr 29, 2006 6:11 am
by timvw
ole wrote: Case sensitive functions
Which problem would be solved by making function names case-sensitive?
Where's the advantage of having different results for a doX and DoX call?

How long would it take for the average developer to become aware of this? Even nowadays i still see: 'Help my variables have disappeared (register_globals)' posts...

Still convinced that we need case-sensitivity?
ole wrote: Properly standardized functionNames(), arguments and return types
Cleaner global namespace
Imho, the PHP API was not designed, it just grew into what it's today. On the other hand, for most PHP function calls there seems to be a rationale behind the arguments and their order, so i don't really see how they could make it any easier...

A decent editor/ide will remind you to the function signature and show hints for the arguments..

By cleaning it up (or trying to do so) you're going to break backwards compatibility.. For what?

What i don't like is that there is a trend towards doubling the functions by offering both a Class::Method and a class_method function that do the same. (Note to myself: Is that consistent with what i said about DoX and doX?)
ole wrote: Built-in Optimizer
This is a suggestion i do agree with. Probably because it doesn't influence the 'programmer interface with php'.
ole wrote: Out dated function sets replaced with more comprehensive classes
Which function sets are you referring to? And with what would you replace them?
ole wrote: Bundled with Zend Framework
I don't see why this would be a good thing considering the current status of ZF.
If we consider the bundling of php with pear we already know that it doesn't work ;)
ole wrote: Manatory OO based development (maybe objective input and output streams for example)
And the advantage would be? (Not interested in yet another my methdology is better than yours discussion)
ole wrote: Drop double-quote string syntax?
I'm assuming you're referring to variable variables. What is wrong with it that you would remove the functionality?
ole wrote: Drop variable dollar symbol syntax?
Why drop the syntax? With what would you replace it?
The only reason i can imagine would be aesthetics, and that doesn't seem like a good criterium.
ole wrote: Separating PHP out into two versions would also have psycological implications. For example there would be forums for PHP Classic and forums for PHP Pro and a good deal of the users of these forums would stay on one of the other and created separate environments.
In essence, there would be a good and a bad version... Why on earth would we need a bad version?

I do know very well that PHP5 has functionality that PHP4 doesn't have. But when i develop an application for a specific target i'll have to live with the constraints of that target. Apparently the constraints that PHP4 has don't stop people from creating solutions for their problems. It's a matter of choosing the right tool for the right job.
ole wrote: Anyway that's my piece. I'm not saying this is a good idea but I'm interested in peoples opinions on this and also people would like to see put into PHP to aid more serious developers.
How would you define 'more serious developers'?
And what would their needs be?
Why would we have to change PHP to suit their needs?
Since they're more serious developers, can't they make it theirselves instead of harassing us with it? :)

Personally i do see a need for:
- namespaces.. Eg: Which framework doesn't have a Date class?
- unicode

- since the default content-type for php is text/html i would expect the default output for echo/print calls to use htmlentities. This way it becomes harder for average php programmers to shoot themselves in the foot. On the other hand, magic_quotes hasn't helped either.. PHP is doomed.. It's relatively easy to use, so you will see lots of code written by beginners.. Just like you could see a lot of Visual-Basic code... And yes, in the end PHP will get the same reputation as Visual-Basic by so-called 'serious developers'.

Posted: Sat Apr 29, 2006 11:43 am
by Christopher
d11wtq wrote:
ole wrote:is that php?
No its ruby :? I'm confused too. What are you referring to arborint? :)
Yep. You are asking for some language changes and a standard framework. It sounds like Ruby may be closer to what you want than PHP6. RoR is an excellent solution. PHP6 will certainly provide some of what you are asking for though.

Re: 2 PHP Versions: Classic and Pro

Posted: Sat Apr 29, 2006 12:33 pm
by alex.barylski
timvw wrote:
ole wrote: Case sensitive functions
Which problem would be solved by making function names case-sensitive?
Where's the advantage of having different results for a doX and DoX call?

How long would it take for the average developer to become aware of this? Even nowadays i still see: 'Help my variables have disappeared (register_globals)' posts...

Still convinced that we need case-sensitivity?
ole wrote: Properly standardized functionNames(), arguments and return types
Cleaner global namespace
Imho, the PHP API was not designed, it just grew into what it's today. On the other hand, for most PHP function calls there seems to be a rationale behind the arguments and their order, so i don't really see how they could make it any easier...

A decent editor/ide will remind you to the function signature and show hints for the arguments..

By cleaning it up (or trying to do so) you're going to break backwards compatibility.. For what?

What i don't like is that there is a trend towards doubling the functions by offering both a Class::Method and a class_method function that do the same. (Note to myself: Is that consistent with what i said about DoX and doX?)
ole wrote: Built-in Optimizer
This is a suggestion i do agree with. Probably because it doesn't influence the 'programmer interface with php'.
ole wrote: Out dated function sets replaced with more comprehensive classes
Which function sets are you referring to? And with what would you replace them?
ole wrote: Bundled with Zend Framework
I don't see why this would be a good thing considering the current status of ZF.
If we consider the bundling of php with pear we already know that it doesn't work ;)
ole wrote: Manatory OO based development (maybe objective input and output streams for example)
And the advantage would be? (Not interested in yet another my methdology is better than yours discussion)
ole wrote: Drop double-quote string syntax?
I'm assuming you're referring to variable variables. What is wrong with it that you would remove the functionality?
ole wrote: Drop variable dollar symbol syntax?
Why drop the syntax? With what would you replace it?
The only reason i can imagine would be aesthetics, and that doesn't seem like a good criterium.
ole wrote: Separating PHP out into two versions would also have psycological implications. For example there would be forums for PHP Classic and forums for PHP Pro and a good deal of the users of these forums would stay on one of the other and created separate environments.
In essence, there would be a good and a bad version... Why on earth would we need a bad version?

I do know very well that PHP5 has functionality that PHP4 doesn't have. But when i develop an application for a specific target i'll have to live with the constraints of that target. Apparently the constraints that PHP4 has don't stop people from creating solutions for their problems. It's a matter of choosing the right tool for the right job.
ole wrote: Anyway that's my piece. I'm not saying this is a good idea but I'm interested in peoples opinions on this and also people would like to see put into PHP to aid more serious developers.
How would you define 'more serious developers'?
And what would their needs be?
Why would we have to change PHP to suit their needs?
Since they're more serious developers, can't they make it theirselves instead of harassing us with it? :)

Personally i do see a need for:
- namespaces.. Eg: Which framework doesn't have a Date class?
- unicode

- since the default content-type for php is text/html i would expect the default output for echo/print calls to use htmlentities. This way it becomes harder for average php programmers to shoot themselves in the foot. On the other hand, magic_quotes hasn't helped either.. PHP is doomed.. It's relatively easy to use, so you will see lots of code written by beginners.. Just like you could see a lot of Visual-Basic code... And yes, in the end PHP will get the same reputation as Visual-Basic by so-called 'serious developers'.
Which problem would be solved by making function names case-sensitive?
Where's the advantage of having different results for a doX and DoX call?
No problem...just promotes consistency a little more...

someFunction
SomeFunction

Different functions and you better remember that...so it makes you want to stick with a consistent convention...

Tis how I would see a benefit in it...

Honestly I didn't even realize you *could* write PHP functions in different case and get away with it... :P
Imho, the PHP API was not designed, it just grew into what it's today. On the other hand, for most PHP function calls there seems to be a rationale behind the arguments and their order, so i don't really see how they could make it any easier
Thats not really opinion, it's pure fact and obvious by the inconsistent nature of function signatures...yes there is some order and convention to some functions...for instance the array_* functions but why then don't all the functions begin with array

Like count()? Sure it returns the properties in a object as well, but now we have get_class_vars/get_object_vars for that...

I can live with it, as I accept it as the "norm" but by no means is the inconsistent API considered ideal...
A decent editor/ide will remind you to the function signature and show hints for the arguments..
Although I agree a good editor is a great choice...thats the wrong way to solve the problem...but for the time being the only way to solve the problem...as the API pretty much can't change for backwards compatability reasons...
By cleaning it up (or trying to do so) you're going to break backwards compatibility.. For what?
You can't, I agree...you would break to much code...but ideally it would be nice...
And the advantage would be? (Not interested in yet another my methdology is better than yours discussion)
Agreed...as big of an OOP zealot as I am...I can't say that using it ALL THE TIME is a great idea in an interpreted environment...
I'm assuming you're referring to variable variables. What is wrong with it that you would remove the functionality?
Don't think he means variable variables... :? I think he means double quoted strings...in which case...I'm not a fan but they do come in handy...so that would be silly...
PHP is doomed.. It's relatively easy to use, so you will see lots of code written by beginners.. Just like you could see a lot of Visual-Basic code... And yes, in the end PHP will get the same reputation as Visual-Basic by so-called 'serious developers'
:lol: :lol: :lol:

Very true...but...all languages are like that...todays new ones anyways...real programmers write software in C++ we all know that...professionals don't need garbage collection... :P

The only problem is...very few people have every written entire applications using C/C++ as it's a daunting task, especially if your like me and want control over everything, like OWNER_DRAW menus and controls...thank god for code project and it's plethora of custom controls... ;)

Only half of them suck to much to use in an real application :)

I like PHP for that reason - it's ease of use...and thats the reason I don't generally use pre-written code unless it's clearly done right...

PHP has it's place in quickly developing large enterprise of small utility type applications quickly and effectively...so long as it works on the user end of things...it doesn't *really* matter how or what it was developed in...

Cheers :)

Posted: Sat Apr 29, 2006 2:04 pm
by Ollie Saunders
Respect Hockey, you made a lot replies for me there, clearly we share a lot of opinion. Ahh this is what debate is about.
By cleaning it up (or trying to do so) you're going to break backwards compatibility.. For what?
You can't, I agree...you would break to much code...but ideally it would be nice...
Well yes that's why i'm suggesting separate versions so this isn't a problem. You wouldn't be able to make hardly any of these changes were it not for that fact.
Don't think he means variable variables... Confused I think he means double quoted strings...in which case...I'm not a fan but they do come in handy...so that would be silly...
Useful? They do the same thing as concat operator and single quotes only not as well. Personally i think "Hello {$array['index']}" notation is utter madness when there is a perfectly good 'Hello '. $array['index'] syntax. Obviously if we were to drop double-quotes then single quotes would need to have all the \n \r \t etc. escapes added.
Very true...but...all languages are like that...todays new ones anyways...real programmers write software in C++ we all know that...professionals don't need garbage collection...
lol. A lot of the points I'm making here would bring PHP slightly closer to C++, certainly add more structure. Of course one of my main likes about PHP is the amount you can get done with such few lines; even compared to other high level interpreted languages. so I would never propose down levelling to any extent.

----------------------
Yep. You are asking for some language changes and a standard framework. It sounds like Ruby may be closer to what you want than PHP6. RoR is an excellent solution. PHP6 will certainly provide some of what you are asking for though.
Ruby is a completely different language. I think PHP is closer to what I like than Ruby is mainly because you can add structure to PHP through standardized ways of working and frameworks but you can't make Ruby more procedural.

-------------------------
Drop variable dollar symbol syntax?
Why drop the syntax? With what would you replace it?

The only reason i can imagine would be aesthetics, and that doesn't seem like a good criterium.
Don't replace it with anything. Why do we need a dollar in front of every variable? It seems to make the whole language a lot more symbolic and harder to read (not to mention type).

Code: Select all

for($i=0,$j=count($array);$i<$j;$i++) {}

Code: Select all

for(i=0,j=count(array);i<j;i++) {}
I know which I prefer.
Obviously you would keep a dollar symbol for things such as variable variables then it would have some purpose.
In essence, there would be a good and a bad version... Why on earth would we need a bad version?
No a good version and a backwards compatible legacy version that would, yes, ultimately die out.
How would you define 'more serious developers'?
And what would their needs be?
People who use PHP for a living and need a more structured and standardized language.
Why would we have to change PHP to suit their needs?
Since they're more serious developers, can't they make it theirselves instead of harassing us with it?
Because of the flaws I've outlined. And I'm not harassing anyone this is just a discussion. If you feel harassed unsubscribe from the thread.
Personally i do see a need for:
- namespaces.. Eg: Which framework doesn't have a Date class?
- unicode
I deliberately didn't mention namespaces because that's been talked about so much and unicode is already in the pipeline.
since the default content-type for php is text/html i would expect the default output for echo/print calls to use htmlentities.
Errr...so you wouldn't actually be able to output any HTML just HTML entities?!
This way it becomes harder for average php programmers to shoot themselves in the foot. On the other hand, magic_quotes hasn't helped either..
You shouldn't try to fix stupid script kiddies with language constructs the magic_quotes mess has proved that to be true.

Posted: Sat Apr 29, 2006 2:42 pm
by alex.barylski
Well yes that's why i'm suggesting separate versions so this isn't a problem. You wouldn't be able to make hardly any of these changes were it not for that fact.
Fare enough, but I think that's what Arborint was getting at when he said there already exists something which does what you suggest, as in RoR...

No it's not PHP, it's RoR but it does more of what you say and better...

2 versions of PHP doesn't make sense, in that sense :? I hate when I word sentances like that :P

Really though, PHP is what it is...and it can't change for backwards compatability reasons...

By changing it, you essentially just invented a new language/technology...so you might as well use Ruby.

No one is going to adopt a second more professional version of PHP because, they might as well go out and start using Ruby if their that concerned with standards, etc...

See what i'm saying?

You couldn't write software for one PHP version (the pro edition) and exepct it to work on the basic version...thus, the backwards compatability issue...
Useful? They do the same thing as concat operator and single quotes only not as well. Personally i think "Hello {$array['index']}" notation is utter madness when there is a perfectly good 'Hello '. $array['index'] syntax. Obviously if we were to drop double-quotes then single quotes would need to have all the \n \r \t etc. escapes added
Not sure what your saying here...you need to escape special characters regardless of single or double strings...

I agree...they are ugly...and make for confusing code at times...as concatenation is more programmer obvious, but they are still nice at times..

When I have a list of error messages and I want to insert a code into that message...I often use interpolation over concatenation as my array of strings then just looks cleaner and it's obvious to me interpolation is occuring...

There are times when both come in handy but I do favour concatenation over interpolation 9 times out of 10...
lol. A lot of the points I'm making here would bring PHP slightly closer to C++, certainly add more structure. Of course one of my main likes about PHP is the amount you can get done with such few lines; even compared to other high level interpreted languages. so I would never propose down levelling to any extent.
It's a far cry from C++ as with most languages...

What you suggest would make PHP better I'm not disputing that...but what I am saying is I think you have to just wait until the core development team implement your features in upcoming versions...

It doesn't really make sense to have two concurrent versions, one with features and one without...unless from a business standpoint your giving away the free and offering the pro for price...

If this is what your considering doing...oh man...have fun...thats a tremendous amount of work and requires quite an extensive skillset...parsing source code alone...is quite difficult, nevermind emulating an execution environment, implementing proper garbage collection, OOP, etc...

Way too much work for one man to do anything useful...and you'll have a heck of a time getting any kind of team togather for the reasons I mentioned above...

If you need more than PHP offers, use ruby, otherwise wait until PHP gets there...

Now if you had a totally new idea, like start a language which supported only pure OOP with features that are typically only supported compiled languages like const modifiers on methods, etc..maybe pointers support and a pre-processor like C has...maybe then you could drum up support...I would be possibly be interested in a PHP equivelant with macros...god I miss those things sometimes...

Cheers :)

Posted: Sat Apr 29, 2006 2:49 pm
by alex.barylski
Don't replace it with anything. Why do we need a dollar in front of every variable? It seems to make the whole language a lot more symbolic and harder to read (not to mention type).
That would be a bad idea...

I have become so accustomed to the dollar sign being infront of variables...

It would be like removing the ubiquitous semi-colon from statements...

Heck I even sometimes use $ in C++ still...it's difficult to get over...
People who use PHP for a living and need a more structured and standardized language.
I hear you man...really I do....but thats life...

Legacy code is a huge problem in software development and at times keeps us from evolving...

Just look at OODBMS versus RDBMS :P

Posted: Sat Apr 29, 2006 3:13 pm
by Ollie Saunders
What you suggest would make PHP better I'm not disputing that...but what I am saying is I think you have to just wait until the core development team implement your features in upcoming versions...

It doesn't really make sense to have two concurrent versions, one with features and one without...unless from a business standpoint your giving away the free and offering the pro for price...

If this is what your considering doing...oh man...have fun...thats a tremendous amount of work and requires quite an extensive skillset...parsing source code alone...is quite difficult, nevermind emulating an execution environment, implementing proper garbage collection, OOP, etc...
No i'm not suggesting to start writing a new language. I couldn't do it. But it would be great.
Now if you had a totally new idea, like start a language which supported only pure OOP with features that are typically only supported compiled languages like const modifiers on methods, etc..maybe pointers support and a pre-processor like C has...maybe then you could drum up support...I would be possibly be interested in a PHP equivelant with macros...god I miss those things sometimes...
Hockey? Hockey? Hockey? Hockey are you there?
Ah there you are. I think we lost you for a moment there.
No it's not PHP, it's RoR but it does more of what you say and better...
Someday probably this year I will look into RoR. But for now I'm not interested simply because I've yet to find a limit for what PHP can do and PHP is much faster than RoR.
That would be a bad idea...
I have become so accustomed to the dollar sign being infront of variables...
Sure it would be radical but I don't think it would be difficult to adjust to considering how many other languages go without it.

Posted: Sat Apr 29, 2006 3:14 pm
by d3ad1ysp0rk
How is this practical at all?

First of all, if you can isntall PHP4, you can install PHP5. Installation is easy. If you can program, you can read and execute one of hundreds of tutorials on the issue.

Secondly, have you seen the insane amount discrepencies between hosts when it comes to PHP versions? Not only do some refuse to upgrade to PHP5, but they won't even waste their time installing the newest version of 4! This leads to the conclusion that another version would not only not get installed on many hosts, but therefore, would not encourage any open source development or free software.

It's hard enough convincing people to develop for free. Imagine how difficult it would be if they knew the people who would benefit were 1/1000th the amount?

If you're good at developing in the language PHP is written in, why not help them out?

Posted: Sat Apr 29, 2006 4:11 pm
by Ollie Saunders
If you can program, you can read and execute one of hundreds of tutorials on the issue.
On what issue?
Secondly, have you seen the insane amount discrepencies between hosts when it comes to PHP versions?
-----------------------
That was one of my suggestions:
Fewer PHP.ini configurations in favour of new special runtime configuration syntax
------------------------
If you're good at developing in the language PHP is written in, why not help them out?
That's C. and I'm simply making a discussion here. I'm not actually going to do any of this for reasons I've stated in the thread.

Posted: Sat Apr 29, 2006 5:03 pm
by d3ad1ysp0rk
ole wrote:
If you can program, you can read and execute one of hundreds of tutorials on the issue.
On what issue?
PHP 5 was a bold step that I have come to appreciate but it has inadvertently created two strains of PHP developer. Those who have the ability to configure their own server and install PHP 5 and those that don't and are stuck with PHP 4.
ole wrote:
Secondly, have you seen the insane amount discrepencies between hosts when it comes to PHP versions?
-----------------------
That was one of my suggestions:
Fewer PHP.ini configurations in favour of new special runtime configuration syntax
------------------------
Uhh, I didn't mean configurations, I meant versions. Like 4.4.2 vs 4.3.x. When they improve things, not all programmers can take advantage of even those, due to legacy php4 installs. A new branch of the language would be impossible to keep updated if they can't even keep one of the most popular server side languages current.
ole wrote:
If you're good at developing in the language PHP is written in, why not help them out?
That's C. and I'm simply making a discussion here. I'm not actually going to do any of this for reasons I've stated in the thread.
Well, I had assumed you were saying something like "I don't like the direction PHP is going" or "They don't work fast enough so I'm going to fix the bugs/problems myself", etc. If you're just suggesting a new version, why not submit your ideas to the developers?

Re: 2 PHP Versions: Classic and Pro

Posted: Mon May 01, 2006 6:08 am
by timvw
Hockey wrote: No problem...just promotes consistency a little more...

someFunction
SomeFunction

Different functions and you better remember that...so it makes you want to stick with a consistent convention...
What is inconsistent about saying that DoX and doX are the same?

I've never heared someone complain about the fact that SQL would be inconsistent because FROM is the same as from is the same as From as ...

Do you really mean that you would find the following easy to remember?

Echo // echo with first character uppercase
echo // echo with all chars in lowercase
ECHO // echo with all chars in uppercase
eCho // echo with second char in uppercase
ecHo // echo with thrid char in lowercase