Re: [PHP-DEV] PATCH: Implementing closures in PHP (was: anonymous functions in PHP)
2007/12/22, Christian Seiler <[EMAIL PROTECTED]>: > > Hi, > > I was following this thread and came upon Jeff's posting on how closures > could be implemented in PHP. > > Since I would find the feature to be EXTREMELY useful, I decided to > actually implement it more or less the way Jeff proposed. So, here's the > patch (against PHP_5_3, I can write one against HEAD if you whish): > > http://www.christian-seiler.de/temp/closures-php-5-3.patch > Hi, I finally got some time to check out your patch (the first and the second version). It looks cool, works as expected in most of the things I've tried. Nevertheless, I don't need this feature, it doesn't provide any advantage over the functor objects I've been using since long. Closures and anonymous functions are harder to maintain and debug, and they are not as elegant as their counterparts in functional languages (lambda functions). On the other side, functor objects are more maintainable, scalable, elegant, and versatile (and php already supports them... it could be improved though). Bottom line, excellent work. If a considerable part of the php user base need this, excellent, they have an implementation which seems viable. But, sorry, I couldn't care less about closures or anonymous functions. Anyway, my opinion doesn't matter, I'm just one user. Best Regards, Martin Alterisio
Re: [PHP-DEV] PATCH: Implementing closures in PHP
Cool. I hope I'll have the time to give that a shot over the holidays. Great work, nice patch (from what I, with my rubbish knowledge, can tell :D) David Am 23.12.2007 um 14:40 schrieb Christian Seiler: Hi David! One question about the names you generate for the function table in combination with opcode caches. [...] I now updated the patch so that this problem is addressed. You will find it here: http://www.christian-seiler.de/temp/closures-php-5-3-v2.patch The compiled functions are now named __compiled_lambda_$hash_$counter, where $counter is a per-file lambda counter and $hash is a hash made from the file name (see hash_compiled_filename in zend_compile.c, I wasn't sure how good Zend's hash function is with duplicates so I hashed the file name AND its basename - feel free to change that function if you have a better idea or know it's safe to only hash the filename itself because duplicates are too rare). Regards, Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PATCH: Implementing closures in PHP
Hi David! > One question about the names you generate for the function table in > combination with opcode caches. [...] I now updated the patch so that this problem is addressed. You will find it here: http://www.christian-seiler.de/temp/closures-php-5-3-v2.patch The compiled functions are now named __compiled_lambda_$hash_$counter, where $counter is a per-file lambda counter and $hash is a hash made from the file name (see hash_compiled_filename in zend_compile.c, I wasn't sure how good Zend's hash function is with duplicates so I hashed the file name AND its basename - feel free to change that function if you have a better idea or know it's safe to only hash the filename itself because duplicates are too rare). Regards, Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PATCH: Implementing closures in PHP
Hi! > Just a minor note; The semi-colon after the closing brace, seems > superfluous. Is there any reason for it? Unfortunately, yes. The problem is that the closure must be an expression so it can a) be assigned to a variable and b) returned directly. And since the expression is only a part of a statement, I can take no influence at that point in the grammar as to whether a semicolon should follow or not. I don't see any way of removing the semicolon without a) either making the language inconsistent and/or b) adding a lot of bloat to the grammar. Regards, Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
