SitePoint Sponsor

User Tag List

Page 4 of 4 FirstFirst 1234
Results 76 to 95 of 95
  1. #76
    SitePoint Member
    Join Date
    Jun 2006
    Posts
    9
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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

  2. #77
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Selkirk
    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.
    Quote Originally Posted by kyberfabrikken
    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...

  3. #78
    SitePoint Enthusiast kozuch82's Avatar
    Join Date
    Mar 2006
    Location
    Proudly European
    Posts
    52
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I am sooo looking forward to PHP6!!! ))

  4. #79
    SitePoint Enthusiast
    Join Date
    Oct 2004
    Location
    Ohio
    Posts
    40
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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!

  5. #80
    SitePoint Wizard dreamscape's Avatar
    Join Date
    Aug 2005
    Posts
    1,080
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by TNGraham
    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

  6. #81
    SitePoint Zealot whytewolf's Avatar
    Join Date
    Mar 2006
    Location
    montana
    Posts
    104
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    my current wish list for php is rather short and I know that 1 of them will never happen

    PHP Code:
    $class::$method('parm1'); 
    yes reflection handles some of what this should do but not all of it
    and
    PHP Code:
    $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

  7. #82
    Web developer Carl's Avatar
    Join Date
    Sep 2003
    Location
    sweden
    Posts
    320
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  8. #83
    SitePoint Wizard bronze trophy devbanana's Avatar
    Join Date
    Apr 2006
    Location
    Pennsylvania
    Posts
    1,736
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 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.
    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.

  9. #84
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by TNGraham
    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.

  10. #85
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by whytewolf
    my current wish list for php is rather short and I know that 1 of them will never happen

    PHP Code:
    $class::$method('parm1'); 
    yes reflection handles some of what this should do but not all of it
    and
    PHP Code:
    $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...

  11. #86
    SitePoint Addict
    Join Date
    Jan 2005
    Location
    Ireland
    Posts
    349
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by TNGraham
    ... 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.

  12. #87
    SitePoint Zealot whytewolf's Avatar
    Join Date
    Mar 2006
    Location
    montana
    Posts
    104
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac
    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

  13. #88
    SitePoint Wizard bronze trophy devbanana's Avatar
    Join Date
    Apr 2006
    Location
    Pennsylvania
    Posts
    1,736
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Is method1 defined as static? It should work fine.

  14. #89
    SitePoint Wizard dreamscape's Avatar
    Join Date
    Aug 2005
    Posts
    1,080
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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

  15. #90
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yes, I missed it too. Although I think something like this should be trivial to implement:

    PHP Code:
    {$class}::$method() 

  16. #91
    SitePoint Enthusiast
    Join Date
    Oct 2004
    Location
    Ohio
    Posts
    40
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    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.


    Quote Originally Posted by Ryan Wray
    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.

  17. #92
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  18. #93
    SitePoint Enthusiast
    Join Date
    Oct 2004
    Location
    Ohio
    Posts
    40
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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

  19. #94
    SitePoint Evangelist
    Join Date
    Aug 2004
    Posts
    428
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    something i would like to see..

    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
    Last edited by leblanc; Nov 3, 2006 at 22:19. Reason: guess what i found

  20. #95
    SitePoint Addict
    Join Date
    Nov 2005
    Location
    Moss, Norway.
    Posts
    283
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by TNGraham View Post
    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/


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •