PHP6 - Direction of PHP

[mandar-seo]

I have confused by reading so much of it in one stroke. Can anybody tell me when we could have PHP6 on our table?

With regards,
Mandar Thosar

[Ezku]

As I understand it, closures are slated for 6. This is a fantastic feature.

Aww, look at what you made me do. There's drool all over.

My guess is that real closures (lexical scope and first-class functions) is probably too big a change to the language to ever be feasible. Inline blocks in ruby style should be possible though, and a big step up above create_function.

We can always hope...

[kozuch82]

I am sooo looking forward to PHP6!!! ))

[TNGraham]

PHP 6 so soon? lol... I still develop for PHP 4.

Anyway, there are a few things I would love to see in PHP 6. One would be the ability to create abstract data types (basically like struct in C/C++). I would also love to be able to create user defined resources that a class can send back. And even more with variables... its nice that PHP6 will have a 64bit int but I would like to also like to be able to force an int to be 32 or 16 bit... maybe even 8bit.

Something I would like to see although it would most likely be some other software that would implement this and not PHP would be to have a preprocessor type system for PHP (again much like with C/C++). It actually would be handy if this was implemented directly into PHP and would run the preprocessor code only the first time a script was executed on the server then would just cache the resulting OP code (much like what Zend Optimizer does anyway). Such a feature would be very handy for application developers.

There are tons of other things I would love to see but these are a few at the top of my list. In any case I'm extremely happy that PHP6 will get rid of register globals and magic quotes!

[dreamscape]

It actually would be handy if this was implemented directly into PHP and would run the preprocessor code only the first time a script was executed on the server then would just cache the resulting OP code (much like what Zend Optimizer does anyway). Such a feature would be very handy for application developers.

FYI, Zend Optimizer does not cache op codes. It's a common misconception.

Also, Have you read the PHP 6 list? They say they are going to bundle APC by default. Not enabled by default since you have to configure and set it up some manually, but it will be much easier to include when you compile PHP:

http://www.php.net/~derick/meeting-n...stribution-apc

[whytewolf]

my current wish list for php is rather short and I know that 1 of them will never happen

$class::$method('parm1'); 

yes reflection handles some of what this should do but not all of it
and

$simplelayer->subclass('parm1')->subsubclass('parm2'); 

ok so that ones just a cosmetic change really as everything can be broken down into varables instead of calling directly

[Carl]

My biggest wish for PHP is to be able to write (and compile) a C extension in less than 50 lines of code and be able to understand it. On Windows or Linux. Right now it is total gibberish and takes more lines of code than any normal developer is willing to deal with.

The accompanying wish is to be able to run an extension in safe_mode.

[devbanana]

My biggest wish for PHP is to be able to write (and compile) a C extension in less than 50 lines of code and be able to understand it. On Windows or Linux. Right now it is total gibberish and takes more lines of code than any normal developer is willing to deal with.

Agreed. I've not yet messed with building extensions for PHP, but it'd be very nice if it wasn't that hard to do.

[kyberfabrikken]

Something I would like to see although it would most likely be some other software that would implement this and not PHP would be to have a preprocessor type system for PHP (again much like with C/C++). It actually would be handy if this was implemented directly into PHP and would run the preprocessor code only the first time a script was executed on the server then would just cache the resulting OP code (much like what Zend Optimizer does anyway). Such a feature would be very handy for application developers.

I fail to see the purpose of a preprocessor in an interpreted language like PHP.

[BerislavLopac]

my current wish list for php is rather short and I know that 1 of them will never happen

$class::$method('parm1'); 

yes reflection handles some of what this should do but not all of it
and

$simplelayer->subclass('parm1')->subsubclass('parm2'); 

ok so that ones just a cosmetic change really as everything can be broken down into varables instead of calling directly

Can you explain what you had in mind? Both of these are possible right now, at least as I understood what you meant...

[Ryan Wray]

... One would be the ability to create abstract data types (basically like struct in C/C++) ...

Why would such a thing be needed? A struct is pretty much a class without any behaviour, and as such you can write a struct by simply using the class construct and only use variables neglecting functions. The only difference is terminology.

[whytewolf]

Can you explain what you had in mind? Both of these are possible right now, at least as I understood what you meant...

the first will give a T_PAAMAYIM_NEKUDOTAYIM error, while reflection and call_user_func(_array) are work arounds, they don't let $this function from within. {see mixins}

the second works, I seem to remeber it not working not to long ago and would throw up a parse error. oh well thats one thing off my list

[devbanana]

Is method1 defined as static? It should work fine.

[dreamscape]

Look at his code again. He is not doing Class::$method which does work. He is doing $class::$method where I assume he wants $class to be a string containing a class name, since calling methods statically on an instantiated object has no purpose (and does not work either anyway).

Dynamically calling a method/function using a variable that holds the name of the method/function only works for methods & functions; It doesn't work for class names. There you have to use call_user_func() or call_user_func_array()

PS. I also did not catch the $ in $class either until I looked at it a few times

[BerislavLopac]

Yes, I missed it too. Although I think something like this should be trivial to implement:

{$class}::$method() 

[TNGraham]

I fail to see the purpose of a preprocessor in an interpreted language like PHP.

The point of having a preprocessor for PHP would be that logic takes resources and time. For example if you had a statement that only runs if the application is running on say a Linux system then it would cut down on the resources needed (how ever small of an advantage that would be in whatever chase its implemented in). In addition a #define statement would change the standard constant which takes up runtime memory and processing time to define, access, and undefine (upon shutdown) the constant to some sort of literal (either string, bool, int or whatever) that would take up slightly less procesing time and memory (in some cases... there probably would be cases where using #define for some string literals might actually be less efficient then just having the one constant). Also a third example simply comes from a way that the Zend API uses #define to create all the functions that are packaged with PHP... basically EVERY function in php is defined by using ZEND_FUNCTION(function_name) which translates to the actual function which looks something like this... void zif_function_name(INTERNAL_FUNCTION_PARAMETERS). The "INTERNAL_FUNCTION_PARAMETERS" translates into a lot of junk that is not needed in this example but basically being able to define stuff like that would make it easy to create APIs and other large systems.

Why would such a thing be needed? A struct is pretty much a class without any behaviour, and as such you can write a struct by simply using the class construct and only use variables neglecting functions. The only difference is terminology.

I'll be honest... I don’t exactly know how Zend deals with classes (I've never really had the time to sit down and tinker with it to find out) but I assume that by defining all your abstract data types as classes and thus the actual data as an object it would have more overhead than if PHP created a way of handling the data as data and not a class. I just assume the class definitions and whatnot have more overhead that a struct definition and use would have but then again I'm not 100% certain on that.


As far as the being able to write and compile a PHP extension in less than 50 lines of code... I feel that the actual C code to do the task is probably about as simple as they can make it for developers... they have pretty much tried to abstract the extensions as much as possible from the actual internals of the engine. But I will say that starting and compiling an extension can be hard to do.

[kyberfabrikken]

Both cases (preprocessor and datatypes) sounds to me like a lot more trouble than benefits. Saving a few clockcycles in return for added complexity is rarely a good tradeoff. In the case of a preprocessor, imagine the confusion when people try to figure out whether they're in preprocessor-mode or in interpreter-mode. If you don't believe me, just have a look at the PHP forum and how often people get's confused about serverside and clientside execution.

[TNGraham]

I will have to agree with you on the confusion aspect of it. There are a lot of people who use PHP in its simplest form and have no need or want to figure out all its complexities. For many preprocessor statements would probably just add extra confusion. For me anyway it would mostly be the #define statement that I would like to see.

Anyway an interesting note about the preprocessor... someone did work on a preprocessor for the Google Summer of Code 2006. Check out http://code.google.com/soc/php/about.html

[leblanc]

Previously I had something on my wish list that someone pointed out it already existed.. in a function i would have never guessed.

anyways if this request exists please let me know.

I would like a way to add listeners to the php interpretor. -- create my own stack trace

when the interpretor branches to a function:
excutefunction(void *fnpointer, char *args ){

}

I can replace the internal excutefunction with my own so i can suppress the call or call a different function or simply return a different value [not sure what this is called but in the lines of listeners.]

this way i can build something like http://perl.plover.com/Memoize/doc.html
the memoize module in php.

now adding caching abilties take seconds as opposed to hours[and eliminates a mistake i can make].

i known i can probably eliminate extra code if capabilities were added like these.


guess what i found.. i thought i was going have to look into extending and embedding php .... but the answer looks like it already exists: http://us2.php.net/runkit

look into runkit_function_redefine
look into:
runkit.internal_override




note for some comments above:
for preprocessor directives:
http://us2.php.net/manual/en/languag...s.user-defined

[kgun]

Anyway, there are a few things I would love to see in PHP 6. One would be the ability to create abstract data types (basically like struct in C/C++).

A struct isn't very abstract

Look here:

1. http://php.net/manual/en/language.oop5.abstract.php
2. http://php.net/manual/en/language.oop5.interfaces.php

An interface is a pure abstract class that allows multiple inheritance.

"Program to an interface and not to an implementation".

If you go to amazon and search for php 6, you will find some books.

PHP Snapshots for php 6: http://snaps.php.net/