Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
Hi,
Am Sonntag, den 16.12.2007, 11:56 -0800 schrieb Stanislav Malyshev:
Actually it's the opposite. With create_function, you can bind
variables, by marshalling them to a string and embed them in the
That's not binding. But the problem is, seeing this, one expects
closure. And it's no closure.
Maybe deprecating create_function() and allowing something like that
would be a way to go?
$func = function($arg) {
return $arg;
}
As it is compile time, the issue with Op-Code caches would/should go
away.
cu, Lars
--
Lars Strojny
Senior Software Developer
Neu.de GmbH
Wesselinger Strasse 28
50999 Köln
Eingetragen beim Amtsgericht Köln, HRB 61021
Geschäftsführer: Sven Jan Arndt, Christian Dornhoff
Telefon: 02236-48010-21
Fax: 02236-48010-01
Mobil: 0177-3058654
E-Mail: [EMAIL PROTECTED]
Jabber: [EMAIL PROTECTED]
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
Hi,
Am Montag, den 17.12.2007, 08:44 +0100 schrieb Lars Strojny:
[...]
Maybe deprecating create_function() and allowing something like that
would be a way to go?
$func = function($arg) {
return $arg;
}
What a stupid and useless remark. Ignore me, sorry.
cu, Lars
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
On 12/16/07, Stanislav Malyshev [EMAIL PROTECTED] wrote: Actually it's the opposite. With create_function, you can bind variables, by marshalling them to a string and embed them in the That's not binding. But the problem is, seeing this, one expects closure. And it's no closure. Well, documentation can include the following written using large font: Warning: This is not a closure. PHP doesn't have native means for nested contexts. This construct is just another way of creating usual function during compile-time. (for creating functions in run-time see create_function) -- Alexey Zakhlestin http://blog.milkfarmsoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
On Dec 16, 2007 8:56 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote: I don't see how it'd help anything in debugging. Presumably, a stack trace would now contain file and line number. That's not binding. But the problem is, seeing this, one expects closure. And it's no closure. One might expect that, coming from a language with static scope. Then again, one would also expect global variables in that event. I don't really see this as a huge show stopper. My experience from Javascript (Which probably is the language, that most PHP'ers are likeable to have met anonymous functions in) is, that lesser experienced programmers, are often surprised by static scope. Even if they have used Javascript for a while, they have just assumed, that it was global variables. I think the majority of the users won't miss the feature and those who do, will be able to appreciate why it isn't there. -- troels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 4 Bug Summary Report
PHP 4 Bug Database summary - http://bugs.php.net Num Status Summary (625 total including feature requests) ===[*Compile Issues]== 43389 Open configure ignoring --without-cdb flag ===[Apache2 related]== 38670 Open Whole 4.4.x branch has problem with open_basedir option nested from Apache2 ===[Arrays related]=== 31114 Assigned foreach modify array (works with PHP 5.1) 37451 Open array_multisort fails to trigger by val copy of data (works in PHP = 5.1) 39764 Suspended array_key_exists inconsistent behavior 42177 Open Warning array_merge_recursive(): recursion detected comes again... ===[CGI related]== 42180 Open php in fastcgi environment periodicaly get 90% of CPU ===[Class/Object related]= 39254 Open Refcount error with static variables and object references (PHP4 only) ===[Date/time related] 43472 Open strtotime(first Sunday ... does not work in command line ===[Documentation problem] 29045 Suspended gzopen for URL 36663 Open unexpected difference between zlib.output_compression and ob_gzhandler ===[FDF related]== 34811 Assigned fdf_get_value max size ===[Feature/Change Request]=== 3066 Open Parameter for dns functions to select different DNS 3799 Suspended default_charset brings small incompatibility 3830 Open Function to timeout/break off a function 5007 Analyzed enable no-resolve mode for here docs 5169 Open Missing recursive behavior 5311 Analyzed implement checkdnsrr() and getmxrr() on windows 5575 Open open_basedir to ~ 5601 Analyzed @function() should not turn of error reporting for critical errors 5804 Open parser error if any spaces follow indentifier in with here doc syntax 5883 Assigned --enable-trans-sid modification request 5954 Open Informix can't reliably figure if a text result column is NULL 5975 Open version of strip_tags() that specifies tags to strip (instead of tags to keep) 6118 Open Can not supress runtime warnings on foreach 6268 Open ternary op return only by value 6399 Open checkdate should be able to validate a time as well as a date (timestamp) 6427 Open func_get_arg() does not support references 6503 Open no support for multiple resultset query? 6512 Analyzed sort() Does not sort stings as expected 6574 Open SMTP functions via IMAP c-client library 6680 Open regexps (ereg*) ignores locale settings 6911 Open Problem with array_merge(_recursive) 6927 Suspended 6932 Open Filesize / File_exists and include_path 6993 Open uninstalling is a pain in the ass 7006 Open preg_replace ( string pattern, array replacement, string subject ); 7028 Analyzed xml=shared and wddx do not work together 7132 Assigned fsockopen doesn't report dns lookup failure 7398 Open Stored procedure error return values not passed through 7507 Open Better ODBC error reporting/fetching 7541 Open please consider also support HPUX shl_* 7553 Open RFC: Uplevel Block structure 7559 Open zend_hash_get_current_key_ex returning persistent strings 7578 Open next() and current() do not return referenceing arrays 7808 Open variable value triggerd by function 7923 Analyzed htmlentities doesn't work for ISO 8859-2 7930 Open List() constructor reference assignment 8100 Assigned extract(), extra feature 8108 Analyzed implement trans-sid as output handler 8295 Open absolute path in extension= directive in php.ini not recognized 8395 Open register_shutdown_function() error 8397 Open Multi-results sets are not suppported 8427 Analyzed Unwanted references 8428 Open continue doesn't pass thru a switch statement 8595 Open More effective parsing of list() (+other) 8640 Open enumeration type 8685 Open heredoc: remove column 1 closing identifier requirement 8809 Open Cookieless session with Header redirects 8827 Open PHP_AUTH_PW stores password when using External Authentication 8855 Open session_start should return also FALSE 8897 Open Significant portions of the InterBase API have no PHP representation. 8948 Open readline_completion_function enhance 9095 Open colon/semicolon delimitd extension_dir ? 9195 Analyzed Default class function arguments 9262 Analyzed Inconsistency in the implementation of here-docs 9266 Analyzed Unable to load 14 of php's extensions 9308 Open Allow Unix to use Win32 only mail options
Re: [PHP-DEV] Re: Idea for namespace lookup resolution
Hi Jessie,
The namespace may include several files and it may be extended with
additional files in any moment. So having single
__get_namespace_classes() function will require to update it every time
you extend namespace.
Also such function will significantly slowdown access to internal
classes. (It was the main reason why __autoload() was moved after check
for internal class).
Thanks. Dmitry.
Jessie Hernandez wrote:
Attached is the proof-of-concept patch. If the idea is met well, then
I'll keep working on it to add caching and, if there's interest, I'll
add *namespace imports*.
An example of how a class in a namespace that's named the same as an
internal class can be loaded:
autoload.php
?php
function __autoload($className)
{
include_once str_replace( '::', DIRECTORY_SEPARATOR, $className ) .
'.php';
}
function __get_namespace_classes($namespaceName)
{
return array( 'Exception' );
}
?
test.php
?php
namespace ns;
include 'autoload.php';
$ex = new Exception();
var_dump( $ex ); // prints out ns:Exception instead of Exception
?
I ran a few tests on it and did not find any significant performance
hit. If possible, I'd like someone to try it out and see if they have
the same result.
As always, comments/suggestions on the patch are welcome.
Regards,
Jessie Hernandez
Zend Certified Engineer (http://zend.com/zce.php?c=ZEND006359r=222727282)
Jessie Hernandez wrote:
I just thought of something that might be a solution to the lookup
rules that we currently have in the namespaces implementation. Whether
it's good or not, I just wanted to throw it out there. Here goes:
Support a user-defined function named __get_namespace_classes, which
will be similar to __autoload. The signature of the function would be
the following:
array __get_namespace_classes(string $namespaceName);
Returns an array of names of classes that are under the specified
namespace, or FALSE if the classes under the namespace could not be
determined.
The above function would be used in the lookup rules as follows (using
DateTime as an example):
1) Does the class DateTime exist in the current namespace?
2) If not, and the function __get_namespace_classes exists, call
__get_namespace_classes.
3) If the string DateTime is returned in the array from
__get_namespace_classes, then autoload that class.
4) If the class is not in the resulting array, or if the result was
FALSE, then look for an internal class DateTime.
With the above function, you can define classes inside your namespace
that are named the same as internal classes without having to
explicitly use them all over the place. You also solve the problem
of namespace imports (sorry, use :-) ):
?php
use PEAR::Net::*;
$a = new FTP();
// The above use statement results in calling the
// __get_namespace_classes function and using each class in the
// resulting array internally. Meaning the above will be equivalent to
// this:
//
// use PEAR::Net::Curl;
// use PEAR::Net::DNS;
// use PEAR::Net::FTP;
// ...etc...
?
For the above function to work best, the PHP dir function, as an
example, should be modified to have an additional use_include_path
argument:
object dir(string $directory [, bool $use_include_path])
By passing TRUE as the second argument, the directory will be searched
for in the include path. The user can then do something like the
following as an implementation of __get_namespace_classes (assuming
the user organized it into class per file, as is common):
?php
function __get_namespace_classes($namespaceName)
{
$classes = false;
$nsDir = str_replace( '::', DIRECTORY_SEPARATOR, $namespaceName );
$d = dir( $nsDir, true );
if( $d )
{
$classes = array();
while( ( $file = $d-read() ) !== false )
$classes[] = str_replace( '.php', '', $file );
$d-close();
}
return $classes;
}
?
Let me know what you think!
Regards,
Jessie
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 6 Bug Summary Report
PHP 6 Bug Database summary - http://bugs.php.net Num Status Summary (63 total including feature requests) ===[*General Issues]== 26771 Suspended register_tick_funtions crash under threaded webservers ===[*Unicode Issues]== 42163 Open fgetcsv() gives different output with and without Unicode ===[Apache2 related]== 42209 Open fail on make for sapi/apache2handler/apache_config.lo ===[Arrays related]=== 35277 Suspended incorrect recursion detection 41758 Assigned SORT_LOCALE_STRING broken for sort() in PHP6 43109 Assigned array_intersect() emits unexpected no of notices when 2d array is passed as arg ===[Class/Object related]= 33595 Assigned recursive references leak memory 41461 Assigned E_STRICT notice when overriding methods not defined by an Interface in hierarchy ===[Compile Failure]== 42606 Open unicode/constants.c relies on ICU draft api ===[Feature/Change Request]=== 20377 Open php_admin_value affects _only_ .htaccess 27618 Open curl_multi_info_read does not appear to work 28261 Open Lifting reserved keyword restriction for method names 29479 Suspended changing current process name 34211 Open PDO_OCI: Allow for data type TIMESTAMP(0) WITH LOCAL TIME ZONE 34252 Open Base functions extension and refactoring 34527 Open trim functions extension 34775 Open parse_url() provide better error description on failure 34882 Open Unable to access *original* posted variable name with dot in 35309 Open Database connection pooling 37081 Open Make the include-errors mention faulty permissions 37380 Open DOMDocument-createAttribute[NS] can't set value 37546 Open DOMDocumentFragment-appendXML namespace support 37796 Open t_is_not_identical for ? 38622 Open Proposed new security scheme for shared hosting (safe mode substitute) 38946 Open pecl/docblock should be merged into ext/tokenizer 40013 Open php_uname() doesnt return nodename 40499 Open filter sapi does not register any highlightning filter 41019 Assigned auto update feature for FastCGI for IIS 41119 Open range() function behavior different on PHP6 and PHP5 41602 Open POSIX functions on Windows using Cygwin Library 42262 Open get_magic_quotes_gpc() should be there and return false 42727 Open Zend doesn't fail with syntax error 42922 Open request for 64bit numbers in php6 ===[Filesystem function related]== 27792 Assigned Functions fail on large files (filesize,is_file,is_dir) 42037 Open fgetc() retuns one char when fails to read on php6 42057 Open fwrite() writes data into file when length is given as a negative value 42110 Open fgetcsv doesn't handle \n correctly in multiline csv record 42125 Open fgetss reads an extra char from file created using file_put_content() 42126 Open size of the file differ, when created using file_put_content() on php6 42167 Open fgetcsv gives different output on php6 compared to php5 42219 Open length argument of fgetcsv() is not effective/working in PHP6 42229 Open fgetcsv() behaves differently for a file containing '\n' with php5 and php6. ===[GD related]=== 34670 Assigned imageTTFText for Indian scripts (Devanagari) 34992 Assigned imageconvolution does not respect alpha ===[I18N and L10N related] 42471 Open locale_set_default returns true on invalid locales ===[ODBC related]= 39756 Assigned Crashes in fetching resultsets with LONG ASCII columns from MaxDB ===[OpenSSL related]== 25614 Suspended openssl_pkey_get_public() fails when given a private key ===[Other web server]= 26495 Suspended Using WebSite Pro 2.5 with ISAPI, cookies are not working ===[PDO related]== 35368 Suspended PDO query does not work properly with serialize 39171 Assigned pdo_mysql configure script sets empty default socket 42079 Open pdo_mysql always links to 3.x libraries (== PDO* in HEAD is out-dated) ===[Performance problem]== 42528 Open Out of char(8-bit) range value doesn't roll back, with uni-code ON. ===[Program Execution] 39992 Open
Re: [PHP-DEV] The last PHP 4 release
Hello Derick, what fixes are we talking of, just what is in CVS? Should we also revisit the stuff we use for http://gcov.php.net ? marcus Friday, December 14, 2007, 4:35:08 PM, you wrote: Hello! As we all know, PHP 4's general releases will stop being made at the end of the year. We've two weeks until then, and I think it'd be a good idea to wrap all latest fixes up into PHP 4.4.8. I am planning an RC for next thursday - unless somebody has a strong argument against this. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
Hello Alexey, and for that reason we should do it! Can't Wez simply apply this? marcus Sunday, December 16, 2007, 3:22:40 PM, you wrote: On 12/16/07, Stanislav Malyshev [EMAIL PROTECTED] wrote: I think the problem there is that this syntax wouldn't support external variables, and without them there's not much difference between that and create_function. The difference is, that it is compile-time and create_function is run-time troels knak-nielsen wrote: What was the conclusion on Wez' patch from march [1]? The discussion seemed to steer a bit off, on the discussion of scoping rules, but is there any reason _not_ to implement Wez' patch in HEAD? Even if it doesn't entirely replace create_function, it would be nice to have as a compile-time alternative. [1] http://groups.google.com/group/mailing.www.php-dev/browse_thread/thread/a2c3296dc791369a/075209b288cb28de -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Alexey Zakhlestin http://blog.milkfarmsoft.com/ Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: stevseea
I have PHPT tests to contribute. I am working with others who contribute tests including Raghu Kumar and Zoe Slattery. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: CVSROOT / avail loginfo
Derick Rethans wrote: What is the plan? Assuming there is a plan. -- Sebastian Bergmann http://sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: PATCH: anonymous functions in PHP
I actually remember there was some good discussion on this and there were pretty decent reasons for why this patch was not a full solution and only syntactic sugar, i.e. it didn't do what many expected except for making the syntax nicer. Don't have time right now but we should go back and re-read those discussions before opening a new one. I can probably do it over the next couple of days. I am not necessary against supporting such a solution but we need to make sure it's fully baked and that we clear know and agree on what is and what isn't supported (and that should be documented and not revisited every time someone comes and complains). Variable binding is one thing which would likely not make it into such an implementation unless there's a big shift in the intent of the patch. We really need to get away from this let's just commit it mode on this list. As you saw with garbage collection, namespaces and other recent topics a lot of these topics need significantly more work before they are full baked and ready to actually make it into the code base. The ad-hoc way of committing new features just doesn't work. Andi -Original Message- From: Marcus Boerger [mailto:[EMAIL PROTECTED] Sent: Monday, December 17, 2007 5:10 AM To: Alexey Zakhlestin; Wez Furlong Cc: Stas Malyshev; troels knak-nielsen; internals@lists.php.net Subject: Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP Hello Alexey, and for that reason we should do it! Can't Wez simply apply this? marcus Sunday, December 16, 2007, 3:22:40 PM, you wrote: On 12/16/07, Stanislav Malyshev [EMAIL PROTECTED] wrote: I think the problem there is that this syntax wouldn't support external variables, and without them there's not much difference between that and create_function. The difference is, that it is compile-time and create_function is run-time troels knak-nielsen wrote: What was the conclusion on Wez' patch from march [1]? The discussion seemed to steer a bit off, on the discussion of scoping rules, but is there any reason _not_ to implement Wez' patch in HEAD? Even if it doesn't entirely replace create_function, it would be nice to have as a compile-time alternative. [1] http://groups.google.com/group/mailing.www.php- dev/browse_thread/thread/a2c3296dc791369a/075209b288cb28de -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Alexey Zakhlestin http://blog.milkfarmsoft.com/ Best regards, Marcus -- 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] Re: PATCH: anonymous functions in PHP
and for that reason we should do it! Can't Wez simply apply this? I think we saw numerous examples that commit first, think later approach is not the best one... -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Namespaces *sigh*
Hi Andrew, I think we're on track for including namespaces in PHP 5.3. We've made a lot of progress in the past month on ironing out the implementation thanks to feedback from many people incl. patches by the likes of Greg. There are likely still some minor quirks especially when we start looking outside the core language to places like Reflection APIs but I think we're on track. Andi -Original Message- From: Andrew Mason [mailto:[EMAIL PROTECTED] Sent: Sunday, December 16, 2007 9:25 PM To: internals@lists.php.net Subject: [PHP-DEV] Namespaces *sigh* For those of us who gave up following the namespace debate 150+ emails ago, can someone from the core maintainers let the rest of us plebs know if namespaces are likely to be included any time soon. I've been playing with the patches that were provided by moving our framework over to their own namespace to see how hard it would be ( turns out not very ) and to be honest I am personally chomping at the bit for a namespace implementation to make it into a production release. Is this something that is likely to be resolved and put into a release or should we continue with the craptastic_underscores for a while longer? kind regards Andrew M -- 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] Re: PATCH: anonymous functions in PHP
Andi Gutmans wrote: We really need to get away from this let's just commit it mode on this list. As you saw with garbage collection, namespaces and other recent topics a lot of these topics need significantly more work before they are full baked and ready to actually make it into the code base. The ad-hoc way of committing new features just doesn't work. Amen to that. A long time ago we wanted to use text files in an RFC directory in CVS to discuss new language features. Maybe we should resurrect this idea? -- Sebastian Bergmann http://sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
Well, documentation can include the following written using large font: Warning: This is not a closure. PHP doesn't have native means for nested contexts. This construct is just another way of creating usual function during compile-time. (for creating functions in run-time see create_function) It doesn't help. Nobody reads the docs if he thinks he understands how it should work anyway. Having disclaimer in the manual doesn't do much - we are not worried about being sued, we are worried about feature looking one way and actually working other way. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Idea for namespace lookup resolution
Dmitry,
As I mentioned, I did not find any significant performance penalty with
this patch. Also, the patch can be improved by not checking the
__get_namespace_classes function if we are not currently inside a namespace.
Either way, if we ignore namespace imports, then the best solution would
be the following: commit Greg's patch which allows use ::globalName,
don't generate an error when a class is imported with the same name as
an internal class, and modify the lookup logic so that internal classes
are not even considered when inside a namespace. For example:
a.php
?php
namespace ns;
$a = new Exception( 'test' ); // looks for ns::Exception
?
b.php
?php
$b = new Exception( 'test' ); // not inside namespace, so use
::Exception directly
?
The lookup rules would be:
1. Are we inside a namespace? No - look for internal class named
Exception. Yes - look for ns::Exception.
2. If inside a namespace, and ns::Exception does not exist, then try
autoloading ns::Exception.
3. If ns::Exception does not exist now, then generate an error.
The above would be consistent with how global variables are handled
currently. In order to use a global variable inside a function, you
first need to import it using a global $name statement. The same
would apply here, in order to use a global/internal class, you either
need to reference it using ::name syntax or have a use ::name
statement at the beginning of the file. Since there aren't many internal
classes in the first place, there will be few use ::internalName
statements per file, so this won't burden the user.
I'll try to come up with the patch soon, incorporating Greg's use
::name change.
Regards,
Jessie Hernandez
Zend Certified Engineer (http://zend.com/zce.php?c=ZEND006359r=222727282)
Dmitry Stogov wrote:
Hi Jessie,
The namespace may include several files and it may be extended with
additional files in any moment. So having single
__get_namespace_classes() function will require to update it every time
you extend namespace.
Also such function will significantly slowdown access to internal
classes. (It was the main reason why __autoload() was moved after check
for internal class).
Thanks. Dmitry.
Jessie Hernandez wrote:
Attached is the proof-of-concept patch. If the idea is met well, then
I'll keep working on it to add caching and, if there's interest, I'll
add *namespace imports*.
An example of how a class in a namespace that's named the same as an
internal class can be loaded:
autoload.php
?php
function __autoload($className)
{
include_once str_replace( '::', DIRECTORY_SEPARATOR, $className )
. '.php';
}
function __get_namespace_classes($namespaceName)
{
return array( 'Exception' );
}
?
test.php
?php
namespace ns;
include 'autoload.php';
$ex = new Exception();
var_dump( $ex ); // prints out ns:Exception instead of Exception
?
I ran a few tests on it and did not find any significant performance
hit. If possible, I'd like someone to try it out and see if they have
the same result.
As always, comments/suggestions on the patch are welcome.
Regards,
Jessie Hernandez
Zend Certified Engineer
(http://zend.com/zce.php?c=ZEND006359r=222727282)
Jessie Hernandez wrote:
I just thought of something that might be a solution to the lookup
rules that we currently have in the namespaces implementation.
Whether it's good or not, I just wanted to throw it out there. Here
goes:
Support a user-defined function named __get_namespace_classes, which
will be similar to __autoload. The signature of the function would be
the following:
array __get_namespace_classes(string $namespaceName);
Returns an array of names of classes that are under the specified
namespace, or FALSE if the classes under the namespace could not be
determined.
The above function would be used in the lookup rules as follows
(using DateTime as an example):
1) Does the class DateTime exist in the current namespace?
2) If not, and the function __get_namespace_classes exists, call
__get_namespace_classes.
3) If the string DateTime is returned in the array from
__get_namespace_classes, then autoload that class.
4) If the class is not in the resulting array, or if the result was
FALSE, then look for an internal class DateTime.
With the above function, you can define classes inside your namespace
that are named the same as internal classes without having to
explicitly use them all over the place. You also solve the problem
of namespace imports (sorry, use :-) ):
?php
use PEAR::Net::*;
$a = new FTP();
// The above use statement results in calling the
// __get_namespace_classes function and using each class in the
// resulting array internally. Meaning the above will be equivalent to
// this:
//
// use PEAR::Net::Curl;
// use PEAR::Net::DNS;
// use PEAR::Net::FTP;
// ...etc...
?
For the above function to work best, the PHP dir function, as an
example, should be modified to have an additional use_include_path
argument:
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
On Dec 17, 2007 6:09 PM, Andi Gutmans [EMAIL PROTECTED] wrote: Don't have time right now but we should go back and re-read those discussions before opening a new one. I can probably do it over the next couple of days. I am not necessary against supporting such a solution but we need to make sure it's fully baked and that we clear know and agree on what is and what isn't supported (and that should be documented and not revisited every time someone comes and complains). Variable binding is one thing which would likely not make it into such an implementation unless there's a big shift in the intent of the patch. Allow me to recap then. Static lambdas (in lack of a better name) and create_function() differ from each other in that the former happens at compile time, while the latter happens at run time. The consequence of this is, that you can bind (primitive) variables to the created function, with create_function(), but not with static lambdas. Functionally, create_function() is a variation of eval, which allows you to create new code at runtime. Static lambda is syntactic sugar for creating a function in the global scope, without knowing its name at compile time. Static lambda is more restrictive than create_function(), because there is no way to share scope between the inner and the bounding function. This is specific for PHP, because the language doesn't have static scope. Without going much into details, I think it's pretty safe to say, that introducing static scope into PHP is not only undesireable, but also technically impossible. So let's not spend any time discussing that. In brief, there are the following benefits of introducing static lambdas: A1 Better readability. A2 Syntactic errors happen at compile time, rather than run time. A3 Better support for debugging/introspection. A4 Optimisations are possible. And the following problems: B1 Users might assume, that lambdas have static scope. B2 There is some overlap between the application of create_function() and static lambdas, meaning some level of redundancy. B3 Static lambdas are less powerful, since there is no way to bind variables. If I missed any points, please bring them up. Otherwise, this is what a decision should be based on. (And sorry for pointing out the obvious, but _not_ making a decision, is a decision too) Of the cons, B1 is probably the biggest issue. There are (at least) two considerations to take here; First, how probable is it, that users will make this assumption? And second, how much confusion will it cause to those, which it affects? The first question could perhaps be answered by a survey (Or less scientifically, by random consensus), but the latter is rather subjective. I'd like to make the argument, that those who will tend to suffer most from peculiarities of scoping rules, are the same people, who are less likely to have encountered static scope in the first place. The simple rule, that PHP has dynamic scope, should be simple to understand for anyone who actually knows the difference. Did I miss anything? -- troels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
Hello Stanislav, I do not see anything broken here. All I see is discussing a patch to death just because it doesn't do what everybody wants. marcus Monday, December 17, 2007, 6:14:22 PM, you wrote: and for that reason we should do it! Can't Wez simply apply this? I think we saw numerous examples that commit first, think later approach is not the best one... -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
Functionally, create_function() is a variation of eval, which allows you to create new code at runtime. Static lambda is syntactic sugar for creating a function in the global scope, without knowing its name at compile time. Static lambda is more restrictive than While we are at it, what's wrong with knowing the name? I can see why closure can be fun when you can dynamically use outer-scope variables. But when you can't, what exactly prevents one from just doing the function? two considerations to take here; First, how probable is it, that users will make this assumption? And second, how much confusion will it cause to those, which it affects? First, about 100% on the first encounter for any user ever seeing closures in any other language. Second, all the confusion possible, like oh, closures! cool! let me do this and that! what, I can't use variables?! Are you kidding me?! WTF is it useful for?! place. The simple rule, that PHP has dynamic scope, should be simple to understand for anyone who actually knows the difference. I'm not sure I understand what you mean by static scope and dynamic scope, but anyway thing that looks like closure but works like regular function definition that isn't - is not a very good idea, IMO. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
Hello, Reading the prior discussion, I think either $_SCOPE['x'] or the lexical $x syntax is fine for accessing local variables in the enclosing scope. But closures also should also support $this and static:: when the closure is defined in a method. I think a solution for closures should add a new variable type. That way, the code can compiled at compile time, while the enclosing context (local variables plus $this for methods) can be captured at run time in the new variable type. Also, when the closure value is garbage collected, the references to the enclosing scope and object instance can also be freed. Additionally, the callback psuedo-type could be promoted to the new type, with the string or array representation converted when required. It wouldn't be necessary, but a callback literal along the lines of Array() could also be added to make the conversion unnecessary. I find the following to be easier to understand: set_error_handler(Callback(foo)); Than set_error_handler(foo); The current syntax would still work because of automatic type conversion. Best Regards, Jeff -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
Let me see if I'm understanding you correctly, because that sounds like the
line I'd been thinking along.
--
function baz() {
$var = 5;
$foo = function($a, $b) {
lexical $var;
return $a + $b + $var;
}
return $foo;
}
$func = baz();
function bar($func) {
return $func(2, 3);
}
echo bar($foo); // prints 10
--
Right? Would it be possible to push the heavy lifting onto the compiler
rather than runtime in the above case?
I'm assuming that making the function above GC-able would be a herculean task
at this point, based on previous comments, but I do not actually know myself.
On Monday 17 December 2007, Jeff Moore wrote:
Hello,
Reading the prior discussion, I think either $_SCOPE['x'] or the
lexical $x syntax is fine for accessing local variables in the
enclosing scope. But closures also should also support $this and
static:: when the closure is defined in a method.
I think a solution for closures should add a new variable type. That
way, the code can compiled at compile time, while the enclosing
context (local variables plus $this for methods) can be captured at
run time in the new variable type. Also, when the closure value is
garbage collected, the references to the enclosing scope and object
instance can also be freed.
Additionally, the callback psuedo-type could be promoted to the new
type, with the string or array representation converted when
required. It wouldn't be necessary, but a callback literal along the
lines of Array() could also be added to make the conversion
unnecessary. I find the following to be easier to understand:
set_error_handler(Callback(foo));
Than
set_error_handler(foo);
The current syntax would still work because of automatic type
conversion.
Best Regards,
Jeff
--
Larry Garfield AIM: LOLG42
[EMAIL PROTECTED] ICQ: 6817012
If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an idea,
which an individual may exclusively possess as long as he keeps it to
himself; but the moment it is divulged, it forces itself into the possession
of every one, and the receiver cannot dispossess himself of it. -- Thomas
Jefferson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
On Dec 17, 2007, at 10:30 PM, Larry Garfield wrote:
I'm assuming that making the function above GC-able would be a
herculean task
at this point, based on previous comments, but I do not actually
know myself.
Hi Larry,
Let me use a different example than yours.
function getAdder($x) {
return function ($y) {
lexical $x;
return $x + $y;
}
}
$plusFive = getAdder(5);
$plusTen = getAdder(10);
echo $plusFive(4); // 9
echo $plusTen(7); // 17
If the closure definition (and thus getAddr) returns a string
representing an anonymous function name, then there is no where to
hold the enclosing variable $x and no way to know when to free it.
Notice that in this example, we have two different enclosing contexts,
one where $x is 5 and one where $x is 10.
If we introduce a new variable type, a new kind of zval, then
internally, that variable can hold:
1) A reference to the local variables of getAddr. (here $x)
2) A reference to $this if the closure is declared in a method
3) A reference to the opcodes of the compiled anonymous function.
The opcodes for the closure would be compiled and squirreled away when
the script is compiled.
When getAddr is executed, a zval would be created that holds the
reference to the enclosing locals and a reference to the proper
opcodes. Note that $plusFive and $plusTen would hold two different
zvals, one for each invocation of getAddr, but that both would refer
to the same opcodes structure.
When a codeblock zval is executed, such as at $plusFive(4), the
enclosing context can be passed to the anonymous function function to
make the lexical $x statement bind to the proper variable.
When the zval in $plusFive reaches zero references, it can
subsequently free its references to the local variables of getAddr.
As far as I can see, no herculean garbage collection or reference
counting is required.
Adding a new kind of zval? Perhaps that's Herculean. I don't know.
I hope I've gotten my zval terminology right.
Best Regards,
Jeff
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Fw: [PHP-DEV] CVS Account Request: dharmap
Another reminder for CVS id . I have been working with Raghubansh Kumar Zoe Slattery. Some of my test cases have already been committed with the help of Raghubansh. I have been writing test cases ( array_fill , sizeof etc ) raised some defects too. It would be great if I get a CVS id so that I can contribute to PHP community directly Thank you, Regards Dharma P Dharmanna Pidagannavar, IBM - Forwarded by Dharmanna Pidagannavar/India/IBM on 18/12/2007 09:58 - Dharmanna Pidagannavar/Indi a/IBM To internals@lists.php.net 16/11/2007 16:13 cc Subject [PHP-DEV] CVS Account Request: dharmap Hi Sending a reminder for CVS id request that i had sent earlier. I haven't heard any thing on this. Please provide an CVS id so that i can commit my testcases. Thank you, Regards Dharma hide details Nov 5 (11 days ago) rom Dharmanna Pidagannavar [EMAIL PROTECTED] Rep toly interna [EMAIL PROTECTED] s.php.n et, date Nov 5, 2007 8:20 PM subject [PHP-DE V] CVS Account Request : dharmap mailed-by lists.p
Re: [PHP-DEV] Re: PATCH: anonymous functions in PHP
On Monday 17 December 2007, Jeff Moore wrote:
On Dec 17, 2007, at 10:30 PM, Larry Garfield wrote:
I'm assuming that making the function above GC-able would be a
herculean task
at this point, based on previous comments, but I do not actually
know myself.
Hi Larry,
Let me use a different example than yours.
function getAdder($x) {
return function ($y) {
lexical $x;
return $x + $y;
}
}
$plusFive = getAdder(5);
$plusTen = getAdder(10);
echo $plusFive(4); // 9
echo $plusTen(7); // 17
If the closure definition (and thus getAddr) returns a string
representing an anonymous function name, then there is no where to
hold the enclosing variable $x and no way to know when to free it.
Notice that in this example, we have two different enclosing contexts,
one where $x is 5 and one where $x is 10.
If we introduce a new variable type, a new kind of zval, then
internally, that variable can hold:
1) A reference to the local variables of getAddr. (here $x)
2) A reference to $this if the closure is declared in a method
3) A reference to the opcodes of the compiled anonymous function.
The opcodes for the closure would be compiled and squirreled away when
the script is compiled.
When getAddr is executed, a zval would be created that holds the
reference to the enclosing locals and a reference to the proper
opcodes. Note that $plusFive and $plusTen would hold two different
zvals, one for each invocation of getAddr, but that both would refer
to the same opcodes structure.
So the compiled code is then single-sourced, much the same way that a class is
single sourced and objects simply contain references to it. The Objects can
be GCed whenever, but the class opcodes remain for the life of the script.
When a codeblock zval is executed, such as at $plusFive(4), the
enclosing context can be passed to the anonymous function function to
make the lexical $x statement bind to the proper variable.
When the zval in $plusFive reaches zero references, it can
subsequently free its references to the local variables of getAddr.
As far as I can see, no herculean garbage collection or reference
counting is required.
By separating the opcodes from the zval, you've side-stepped the need to do
so. That means declaring a dynamic function (or lambda, or whatever we end
up calling this thing) inside a loop is no more expensive than instantiating
a class inside of a loop. I'm glad you know more about engine internals than
I do. :-)
Adding a new kind of zval? Perhaps that's Herculean. I don't know.
It sounds (to the layman) like it could/should be modeled on the way
objects/classes are implemented in PHP 5, as fancy references. (I believe
Sara Golemon had an article a while back that explained them that way. Sara,
my apologies if I am misquoting you.) Whether that's a new type of zval or
not I do not know.
I hope I've gotten my zval terminology right.
Better than mine would be. :-) And it seems to solve most of the
implementation concerns that were raised earlier, at least at an abstract
level. The catch would be that I don't know the performance impact of making
the compiler find and define these sorts of functions. Can someone with more
engine experience weigh in if the above is workable?
--
Larry Garfield AIM: LOLG42
[EMAIL PROTECTED] ICQ: 6817012
If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an idea,
which an individual may exclusively possess as long as he keeps it to
himself; but the moment it is divulged, it forces itself into the possession
of every one, and the receiver cannot dispossess himself of it. -- Thomas
Jefferson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
