SitePoint Sponsor

User Tag List

Page 3 of 4 FirstFirst 1234 LastLast
Results 51 to 75 of 95
  1. #51
    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 dbevfat
    I have to disagree with you here, kyber, because if "call_user_func" is implicit, you can't call the "array" version that way. If any of these two is impicit, it should be the "array" function, because you can easily "simulate" the original call_user_func with it.
    Consider this example :
    PHP Code:
    $escape "htmlentities";
    echo 
    $escape("foobar"); 
    I'd find it rather un-intuitive, that I would have to write that as :
    PHP Code:
    echo $escape(Array("foobar")); 
    It's contrary to how real closures work in other languages. Take javascript for example, where you'd have :
    Code:
    f = function(val) {
        return window.escape(val)
    }
    alert(f("foobar"));
    // or
    alert(f.apply(null, ["foobar"]));
    I still see the all_user_func_array as a special case, that you use in situations where you're doing some sort of reflection. In current PHP versions, it's the dominant one, mainly because most people don't use function pointers directly in their code, but if you were writing in a functional style programming, you'd be using it a lot.

    Quote Originally Posted by 33degrees
    PHP Code:
    $func = array(array(& $foo'bar'), array('arg1''arg2')); 
    I don't understand what that's depicting.

  2. #52
    SitePoint Enthusiast
    Join Date
    Jul 2004
    Location
    Finland
    Posts
    73
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by michel
    While we're sharing wishlists... I'd love to see shorthand array notation support, a la JavaScript object literals/JSON .
    Me too, something like $array = ['a':3,'b':'foo',c:['d':'bar']]; would be very nice. I almost never pass array as a parameter(without initiailizing it first), because it looks so ugly

    functioncall(array('foo'=>1),array('bar'=>2));
    functioncall(['foo':1],['bar':2]); //much better

    Arrays have very important role in php, so why not make using them a little less awkward.


    But namespaces is what I'm really waiting for.

  3. #53
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    I don't understand what that's depicting.
    I'm not sure, but I'd assume those are default arguments, so it's a bit like currying.

    Quote Originally Posted by dbevfat
    I have to disagree with you here, kyber, because if "call_user_func" is implicit, you can't call the "array" version that way. If any of these two is impicit, it should be the "array" function, because you can easily "simulate" the original call_user_func with it.
    kyberfabrikken summed the counter-arguments up rather nicely, but I have an addition to make.

    To resolve this, you could have an array expansion operator like in ruby: function foo($arg, *$args) {} where args would capture all the arguments after arg. Combine this with callbacks:
    PHP Code:
    $callback = array($target'method');
    $args = ['arbitrary''number''of''arguments''retrieved''from''elsewhere'];
    $callback(*$args); 
    What I really wish that syntactical sugar such as this – or entirely new functionality for that matter – wouldn't be dismissed because the developers won't bother or feel "it's not the PHP way". Sometimes I feel immensely frustrated at this state of affairs.

    Well, at least we'll get namespaces, won't we?

  4. #54
    SitePoint Wizard HarryR's Avatar
    Join Date
    Dec 2004
    Location
    London, UK
    Posts
    1,376
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ezku
    To resolve this, you could have an array expansion operator like in ruby: function foo($arg, *$args) {} where args would capture all the arguments after arg.
    The traditional ... operator would be a much better candidate, rather than confusing too many people with the pointer/multiply operator.

    For example:
    PHP Code:
    function myPrintf$format$args ... )
    {
      print( 
    count($args) );


  5. #55
    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 Ezku
    I'm not sure, but I'd assume those are default arguments, so it's a bit like currying.
    Ah - I think you may be right.
    Currying is already possible with the current implementation of the callback type. That wouldn't change even if a shorthand call_user_func was introduced.

    Quote Originally Posted by HarryR
    PHP Code:
    function myPrintf$format$args ... )
    {
      print( 
    count($args) );

    No need. You can do :
    PHP Code:
    function myPrintf$format)
    {
      print( 
    func_num_args() );


  6. #56
    SitePoint Guru dbevfat's Avatar
    Join Date
    Dec 2004
    Location
    ljubljana, slovenia
    Posts
    684
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    PHP Code:
    echo $escape(Array("foobar")); 
    It's contrary to how real closures work in other languages.
    I agree, so that's obviously not the correct way to implement it. Ezku provided a valid solution, but it needs another feature to work.

    I still see the all_user_func_array as a special case, that you use in situations where you're doing some sort of reflection. In current PHP versions, it's the dominant one, mainly because most people don't use function pointers directly in their code, but if you were writing in a functional style programming, you'd be using it a lot.
    I still don't think its like this. "call_user_func" and "call_user_func_array" are fundamentally different: one demands a fixed number of arguments that you have to hard-code in the calling code, while the other allows you to have a variable number of arguments that can change at run-time. There are cases where you actually can't use call_user_func at all, unless you want to override default arguments. But you can always use call_user_func_array to delegate calls transparently and without side effects.

    I don't understand what that's depicting.
    PHP Code:
    $func = array(array(& $foo'bar'), array('arg1''arg2')); 
    $func(); 
    means
    PHP Code:
    $foo->bar('arg1''arg2'); 
    It's a call_user_func_array version of your shortcut for call_user_func.

  7. #57
    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 dbevfat
    I still don't think its like this. "call_user_func" and "call_user_func_array" are fundamentally different: one demands a fixed number of arguments that you have to hard-code in the calling code, while the other allows you to have a variable number of arguments that can change at run-time. There are cases where you actually can't use call_user_func at all, unless you want to override default arguments. But you can always use call_user_func_array to delegate calls transparently and without side effects.
    Yeah ... I think we're talking a bit past each other here. I realize the usefulness of *_array. What I'm saying is that I think it's fine to have it as a separate function, rather than supported directly by syntax. Looking at javascript again, it's implemented as a function too, although a bit more elegant, since functions are objects in js and thus can have functions themselves.

    Quote Originally Posted by dbevfat
    PHP Code:
    $func = array(array(& $foo'bar'), array('arg1''arg2')); 
    $func(); 
    means
    PHP Code:
    $foo->bar('arg1''arg2'); 
    It's a call_user_func_array version of your shortcut for call_user_func.
    I get the point now. I don't think that's nescesarry - it's easy enough to curry a callback already.

  8. #58
    SitePoint Enthusiast
    Join Date
    Jul 2004
    Location
    Finland
    Posts
    73
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Closures in PHP5 right now only for you :P. Ok, its just decorator, not real closure support but may be handy in some cases.

    PHP Code:
    <?php
    abstract class JObject{
        
        function 
    getClass(){
            return 
    get_class($this);
        }
        function 
    isInstanceOf($class){
            return (
    $this instanceof $class);
        }
    }

    class 
    Decorator extends JObject{
        protected 
    $obj null;
        
        function 
    __construct($obj){
            
    $this->obj $obj;
        }
        function 
    __get($name){
            return 
    $this->obj->$name;
        }
        function 
    __set($name,$value){
            
    $this->obj->$name $value;
        }    
        function 
    __call($func,$args){
            
    $this->checkMethod($func); 
            return 
    call_user_func_array(array($this->obj,$func),$args);
        }    
        function 
    getClass(){
            return 
    get_class($this->obj);
        }
        function 
    isInstanceOf($class){
            return (
    $this->obj instanceof $class);    
        }
        
        function 
    getObject(){
            return 
    $this->obj;
        }
        
        protected function 
    checkMethod($method){
            if (!
    method_exists($this->obj,$method))
                throw new 
    Exception("Method '$method' doesn't exist in class '".get_class($this->obj)."'!");
        }
        
    }

    class 
    ClosureDecorator extends Decorator{
        
        private 
    $__closures = array();
        
        function 
    closure($method1,$method2){
            
    $this->checkMethod($method1); 
            
    $this->__closures[$method1] = $method2;
        }
        function 
    __call($func,$args){
            if (isset(
    $this->__closures[$func])){
                return 
    call_user_func_array($this->__closures[$func],$args);
            }
            return 
    parent::__call($func,$args);
        }
    }

    class 
    extends JObject{
        
        function 
    b($params){
            echo 
    'A->b()';
        }
        function 
    c($params){
            echo 
    'A->c()';
        }
        
    }
    class 
    extends JObject{
        
        public 
    $property 'test';
        
        function 
    a($params){
            echo 
    'B->a()';
        }
        function 
    c(){
            echo 
    'B->c()';
        }
        
    }

    $a = new A();
    $b = new ClosureDecorator(new B());
    $b->closure('a',array($a,'b'));
    $b->closure('c',array($a,'c'));

    $b->a(3);
    $b->c(3);

    //Output: A->b()A->c()
    ?>

  9. #59
    SitePoint Zealot
    Join Date
    Jul 2004
    Location
    The Netherlands
    Posts
    170
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Off Topic:

    Quote Originally Posted by JaskaS
    I almost never pass array as a parameter(without initiailizing it first), because it looks so ugly
    Yes, aesthetics are important to a lot of coders
    I can't imagine anyone using PHP for aesthetic reasons though
    Lerdorf calls it an 'ugly duckling'.

  10. #60
    SitePoint Wizard dreamscape's Avatar
    Join Date
    Aug 2005
    Posts
    1,080
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ezku
    To resolve this, you could have an array expansion operator like in ruby: function foo($arg, *$args) {} where args would capture all the arguments after arg.
    PHP already has arbitrary argument ability. There's no need to basically duplicate that with another language construct.

    However, I would like to see the behavior of func_get_args()/func_num_args() changed to return only the arguments that aren't declared in the function definition. To me anyways, that is the expected & usually desired behavior. Or at least changing the implementation to take a true/false argument that would allow us to choose the desired behavior would be nice.

    ----

    I would also like to see some kind of internal functionality that allows one to create a class at runtime. If you want to do this now, you have to use eval(), so you have to be careful that no user input can get injected into it. I suppose adding the functionality to the runkit extension would make the most sense; but that extension isn't even bundled with PHP by default let alone enabled by default. However, it would be nice to see something in the core for this, or I suppose I could just keep using eval().

  11. #61
    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 dreamscape
    PHP already has arbitrary argument ability. There's no need to basically duplicate that with another language construct.
    My thought aswell, although I don't think that's what ezku meant. What he proposed was more like a preprocessing macro to expand the array to vars. I don't really like the idea though.

    Quote Originally Posted by dreamscape
    I would also like to see some kind of internal functionality that allows one to create a class at runtime. If you want to do this now, you have to use eval(), so you (...)
    On a related tangent, code blocks would be nice. create_function works, but it feels uncomfortably close to using eval, and it kills all possibility of proper debugging. Also sets off my texteditors syntax highlighter.
    I don't think introducing real lexical scope would mix well with PHP, but blocks a la ruby should do the trick without disruping anything.

  12. #62
    SitePoint Wizard dreamscape's Avatar
    Join Date
    Aug 2005
    Posts
    1,080
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    My thought aswell, although I don't think that's what ezku meant. What he proposed was more like a preprocessing macro to expand the array to vars.
    I don't know, maybe. But even so, that also already exists with call_user_func_array(). And if the PHP meeting notes tell us anything, it is that the developers are not interested in duplicating existing functionality with new language constructs. (In fact a few of the changes to PHP 6 will be removal of some duplicate functionality that already exists in the language)


    Personally don't see why you guys can't just use call_user_func() and call_user_func_array() and be happy with them. They are not that hard to use, are not that hard to read, and are not that ugly to look at.

  13. #63
    SitePoint Wizard bronze trophy devbanana's Avatar
    Join Date
    Apr 2006
    Location
    Pennsylvania
    Posts
    1,736
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think func_get_args() and func_num_args() are best as they are applied now. I find it the most intuitive.

    I know PHP has an implementation for an arbitrary number of arguments, but it's not very clear just by looking at the function declaration, unless the extra parameters are documented. I mean that all we see in the function declaration are the arguments that are required or a few that are optional, but not those that are extras and retrieved with func_get_args() within the function.

    Quote Originally Posted by Michel
    I can't imagine anyone using PHP for aesthetic reasons though
    But what's wrong with trying to write code cleanly?

  14. #64
    SitePoint Wizard dreamscape's Avatar
    Join Date
    Aug 2005
    Posts
    1,080
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by devbanana
    I know PHP has an implementation for an arbitrary number of arguments, but it's not very clear just by looking at the function declaration
    Neither are object overloading methods such __call or __get or __set (typically). But IMO, that is the nature of overloading type features, that the implementation is only going to be really clear to the developer who wrote it (or perhaps another developer if they study it long enough). IMO, the burden falls on the developer to accurately document the public "interfaces" that are created by whatever overloading they do.

  15. #65
    SitePoint Wizard bronze trophy devbanana's Avatar
    Join Date
    Apr 2006
    Location
    Pennsylvania
    Posts
    1,736
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    That's true. Unfortunately, those methods are all too often not very clearly documented.

  16. #66
    SitePoint Zealot
    Join Date
    Jul 2004
    Location
    The Netherlands
    Posts
    170
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Off Topic:

    Quote Originally Posted by devbanana
    But what's wrong with trying to write code cleanly?
    Nothing. Please notice the

  17. #67
    SitePoint Wizard bronze trophy devbanana's Avatar
    Join Date
    Apr 2006
    Location
    Pennsylvania
    Posts
    1,736
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Oops.

    * DevBanana slaps self

    Sorry 'bout that.

    Well anyway, when is PHP6 expected to be released? Haven't heard all too much talk about it, but there has been some....

    We're only on 5.1 though

  18. #68
    SitePoint Zealot
    Join Date
    Oct 2004
    Location
    Worcester
    Posts
    138
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by devbanana
    We're only on 5.1 though
    5.2 any day now

  19. #69
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Be careful what you wish for, you may get it. I'd like to see namespaces, but a bad implementation of namespaces would be worse than no namespaces. From what I've seen so far there are some serious questions about performance, syntax, and compatibility. From my perspective, the goal of a good namespace implementation should be to help integrate code written by different parties into the same PHP application. From what I've seen and understand of the current proposals, I think they fall short of this goal.

    As I understand it, closures are slated for 6. This is a fantastic feature. I hope that closures are implemented as a new type, such as float or integer. Closures are just anonymous functions with some additional variable scoping rules.

    Closures are also very closely related to the callback psuedo-type. Everywhere in PHP today where a callback can be passed to a built in function, that is a candidate for a closure. Note that a closure type is probably 99.9% compatible with callbacks. Because of PHP's weak typing and automatic conversion, a string or array type, which would be interpreted as a callback, can be automatically converted into a closure (or code block) type when necessary.

    I agree that a better syntax for invoking closures/callbacks would be great.

    I'd like to see the myriad of problems with properties get fixed, so that PHP had true declared properties with accessor methods, like every single other popular modern language, instead of the case statement/__get/__set system.

    I fear that the unicode stuff is going to end up bifurcating PHP into PHP 6 unicode programs and PHP 6 non-unicode programs and not just PHP 5 vs PHP 6. I would hate to see another bunch of ini settings that dramatically change how built in functions operate. I don't want to see it get harder to write portable code and I don't want to see the learning cliff get steeper for those who do want to write portable code.

  20. #70
    SitePoint Wizard bronze trophy devbanana's Avatar
    Join Date
    Apr 2006
    Location
    Pennsylvania
    Posts
    1,736
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Just out of curiosity, how does the current implementation of namespaces fall short of the stated goal, in your opinion?

  21. #71
    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 Selkirk
    As I understand it, closures are slated for 6. This is a fantastic feature. I hope that closures are implemented as a new type, such as float or integer. Closures are just anonymous functions with some additional variable scoping rules.
    Where did you read this ?

  22. #72
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    oh.

    I honestly thought that I had read that closures were discussed Here and were to be included. But there is no mention of them there. (or here.) I seriously thought they had made the todo list. I was seriously looking forward to them. I have no idea where I got the idea that they are coming, except perhaps incredibly wishful thinking.

    Its a bit embarrassing, too, because I mention them in my Sep php|arch column, which will probably be out any day now. Bad fact checking, Jeff. Bad fact checking.

    The offending paragraph from my column (as I submitted it):
    Callbacks in PHP still suffer from the lack of an ability to declare anonymous functions. However, closures have been discussed for addition to PHP 6. This bodes well for any future use of the callback style observers. I assume that any closure implementation in PHP would be compatible with callbacks. That is, any built in function that takes a callback parameter could accept a closure parameter. If this is the case, it is possible that many callback based observer implementations might already be forward compatibility to accept closures.

  23. #73
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by devbanana
    Just out of curiosity, how does the current implementation of namespaces fall short of the stated goal, in your opinion?
    Off the top of my head...

    Its been a while since I've looked and apparently I'm not doing a very good job of tracking the PHP 6 stuff. Where are they at with namespaces now and how do they handle defines, globals and autoload?

    Is it possible to wrap non-NS aware code in a NS and use it? Do namespaces help you deal with the versioning problem? Library L1 and L2 both depend on library L3, which they import via a namespace. Can there be two versions of L3 loaded at once in different namespaces?

    My concerns centered around "leakage" between modules. PHP has alot of different global structures, including ini settings, error handlers, etc.

    To me the goal should not be "add namespaces to PHP." The goal should be "make it easy to integrate code from different parties in PHP." Namespaces may work perfectly, but it may still not achieve that goal.

  24. #74
    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)
    Hmm ... that wasn't the answer I was hoping for. But perhaps it can put some preassure on the internal developers to consider the idea ?

    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.
    Last edited by kyberfabrikken; Sep 20, 2006 at 01:15.

  25. #75
    SitePoint Zealot
    Join Date
    Jul 2004
    Location
    The Netherlands
    Posts
    170
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Selkirk
    I seriously thought they had made the todo list. I was seriously looking forward to them. I have no idea where I got the idea that they are coming, except perhaps incredibly wishful thinking.
    Well, closures are on my wishlist as well. And I'm guessing we're not alone
    It's been 10 months since the minutes were published, I'm wondering what the developers have been up to. Forgive my ignorance, but can we discuss feature requests with the development team? Is this even realistic with such a large user base? Neither the general nor internals mailing lists seem appropriate to me.
    Last edited by michel; Sep 20, 2006 at 06:08.


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
  •