Re: [PHP-DEV] autoloading and undefined class constants
On Sun, Jul 5, 2009 at 10:21 PM, Ben Bidner b...@vuetec.com wrote:
per the manual, exceptions thrown in an autoload method are swallowed,
and an E_ERROR is triggered by php.
http://us2.php.net/manual/en/language.oop5.autoload.php
I have read that note before, and wondered exactly what it was referring to
since you can throw exceptions within an autoloader and catch them (or have
your exception handler do whatever it needs to do with them).
?php
function autoloader($className)
{
echo autoloading . PHP_EOL;
throw new Exception(Fail);
}
spl_autoload_register(autoloader);
try
{
// Exception
$obj = new NonExistentClass;
}
catch(Exception $e)
{
echo caught . PHP_EOL;
}
try
{
// Exception
$const = constant(NonExistentClass::NON_EXISTENT_CONSTANT);
}
catch(Exception $e)
{
echo caught . PHP_EOL;
}
try
{
// Fatal error
$const = NonExistentClass::NON_EXISTENT_CONSTANT;
}
catch(Exception $e)
{
echo never happens . PHP_EOL;
}
?
Will output:
autoloading
caught
autoloading
caught
autoloading
PHP Fatal error: Undefined class constant
on both my systems (mentioned in reply to rob) the script fatals after the
first autoloading, just like the manual says..
nat...@trident2:~$ php testcode.php
autoloading
Fatal error: Class 'NonExistentClass' not found in /home/nathan/testcode.php
on line 41
-nathan
Re: [PHP-DEV] autoloading and undefined class constants
On Mon, Jul 6, 2009 at 6:49 AM, Ben Bidnerb...@vuetec.com wrote:
?php
function autoloader($className)
{
throw new Exception(Fail);
}
spl_autoload_register(autoloader);
The whole point of spl_autoload_register() is to allow programmers to
have several independent autoloaders. So, it is a bad practice to
throw exception from autoload — doing so, you forbid system to try the
next autoloader.
Good practice is: if you can't load class from autoloader — just
silently return from it
--
Alexey Zakhlestin
http://www.milkfarmsoft.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] are there alternate interfaces to the bug tracking system?
Hannes Magnusson wrote: On Sat, Jul 4, 2009 at 20:15, Sandro Tosimo...@debian.org wrote: On Sat, Jul 4, 2009 at 18:43, Sean Coatess...@caedmon.net wrote: Just another question: may you please list me all the possible 'Status' field values? In particular we are interested in those 'Status'es that identify the bug as closed and wontfix. I believe all current statuses are declared here: http://cvs.php.net/viewvc.cgi/php-bugs-web/include/functions.inc?view=markup#l82 That's perfect! Thanks a lot for your help! I'll let you know when I'll come up with the final solution. If you can tell us what exactly you need we can hook you up quite easily... You want json result set of status/assigned/last updated/summary/... just let php-webmas...@lists.php.net know and it'll get fixed as soon as someone sees your mail (we can't keep up with the irrelevant traffic on intern...@...) I wouldn't add anything in the current tracker. Just wait a bit and we should have something easier to maintain. (that GSoC thing..) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5 Bug Summary Report
PHP 5 Bug Database summary - http://bugs.php.net/ Num Status Summary (1437 total -- which includes 883 feature requests) ===[*General Issues]== 48597 Open Unclosed array keys break space escaping in $_GET/POST/REQUEST 48612 Open PHP command line interpreter ignores LC_ALL setting 48712 Feedback Page reloading twice when do back in IE 48719 Assigned parse_ini_file scanner more sanitation 48778 Open Files on NTFS Mounted Volumes (Junctions) inaccessible 48793 Open Setting error_log in php.ini causes redirection ===[*Network Functions]=== 48167 To be documented undefined function checkdnsrr() ===[*XML functions]=== 48095 Verified Load RDF Format Error ===[Apache2 related]== 32220 Assigned [PATCH] thread_resources for thread not getting freed when apache kills thread 47681 Open System TMP dir ignored in file uploads 48134 Open crash after a few days (backtrace attached) with worker MPM 48260 Open Size of PHP file affects behaviour of virtual() or #include virtual ===[Arrays related]=== 42838 Assigned Wrong results in array_diff_uassoc (php 5.2.3) 47221 Open no result from array_diff() ===[BC math related]== 44995 Open bcpowmod() using a scale function always returns 0 46564 Verified bcmod( '1071', '357.5' ) returns '0' ===[Bzip2 Related] 29521 Assigned compress.bzip2 wrapper ===[Calendar related]= 40213 Suspended easter_date() returns wrong timestamp if ... ===[CGI related]== 45217 Open crash if -z and -m are used together 47412 Open PHP_MSHUTDOWN_FUNCTION not being called under FastCGI 47605 Open CGI SAPI can not send HTTP 200 header 47627 Open No input file specified causing crash 48695 Open PHP_SELF / SCRIPT_NAME issues not bogus - bugfix in 5.2.9 still causing trouble ===[Class/Object related]= 41461 Verified E_STRICT notice when overriding methods not defined by an Interface in hierarchy 46140 Open Unserializing with __wakeup that removes child causes subsequent refs to shift 46812 To be documented get_class_vars() does not include visible private variable looking at subclass 47405 Verified error reports wrong file/line 47664 Assigned get_class returns NULL instead of FALSE. 48215 Assigned Child calling parent::func calls constructor instead of method (BC break!) 48623 Open Incorrect scope for static variables in object methods 48804 Open Overriding results in declaration error ===[COM related]== 31327 Assigned chinese char and word problem 32099 Assigned After opening ADO connection and closing it repeatedly, Apache stops service 34253 Assigned COM binary object/array issue (question marks?) 35875 Assigned IE event failure upon scheduling script 36360 Assigned PHP crashes when accessing an object that was just create by parent object 37562 Assigned Unable to lookup ParameterFieldDefinitions 37899 Assigned [PATCH] php_char_to _OLECHAR copies junk bytes 37965 Assigned Multi-dimensional array between PHP and COM 38719 Assigned COM Error during accessing function VirtualMachines 40424 Assigned Fatal error when setting the value of COM object's property array 40581 Assigned Pass Struct type to COM object from PHP 40664 Assigned String conversion functions wrong for multibyte chars 41055 Assigned DOTNET not instantiating fully-pathed assembly 41078 Assigned Its not possible to call Static dotNet Classes with dotnet 41189 Assigned Multi-dimensional array in COM function causes hang 41368 Assigned ADODB.Recordset ActiveConnection property - can't set with PHP 5.2.1+ 41388 Assigned Error in COM Object results 41577 Assigned DOTNET is successful once per server run 42413 Assigned Cannot iterate IE's event object 42551 Assigned new COM(HTMLFile) = warnings 42585 Assigned die() in event handler = PHP hangs 43275 Open get_class problem with COM objects 43432 Open Fatal error when setting the value of COM object's Attribute property 43470 Open COM API fails to correctly return [OUT] VT_PTR references 43506 Open com_get_active_object always fails 43521 Open Problem with Variant/Parameters 43838 Open variant_set with IE leads to hang 43897 Open $ie not cleared on IE quit 44256 Open Pb with COM in PHP5 44578 Open Strange Behavior of PHP using COM Object 45704 Open
[PHP-DEV] PHP 6 Bug Summary Report
PHP 6 Bug Database summary - http://bugs.php.net/ Num Status Summary (85 total -- which includes 38 feature requests) ===[*Unicode Issues]== 48265 Open Source and result of database have different encodings. ===[Apache related]=== 47061 Open User not logged under Apache ===[Apache2 related]== 44083 Open virtual() not outputting results if zlib.output_compression = On ===[Arrays related]=== 35277 Suspended incorrect recursion detection 41758 Assigned SORT_LOCALE_STRING broken for sort() in PHP6 43109 Open array_intersect() emits unexpected no of notices when 2d array is passed as arg 48478 Open Super-globals cannot be accessed with literal keys ===[COM related]== 45836 Open cannot use com 46909 Open COM object not allowing calls to methods ===[Compile Failure]== 42606 Open unicode/constants.c relies on ICU draft api 44502 Suspended Compiling ok with MySQL 5.0 ===[Date/time related] 46948 Assigned ext/date/lib/parse_tz.c:99: Memory leak: buffer ===[Filesystem function related]== 42110 Open fgetcsv doesn't handle \n correctly in multiline csv record 44034 Open FILE_IGNORE_NEW_LINES in FILE does not work as expected when lines end in \r\n 46688 Open Return values differ from 5.3 and are also inconsistent 46689 Open Downcoded notices suggest unfinished code in file system? ===[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 ===[ICONV related] 48538 Open iconv_strlen() does not reject invalid charset on PHP6 ===[mcrypt related]=== 46834 Assigned Range of mcrypt functions fail on PHP 6.0 ===[MySQL related] 44076 Open mysql_result returns nothing with blob ===[OpenSSL related]== 25614 Assigned openssl_pkey_get_public() fails when given a private key ===[PDO related]== 35368 Suspended PDO query does not work properly with serialize 48773 Open Incorrect error when setting PDO::ATTR_STATEMENT_CLASS with ctor_args ===[Performance problem]== 42528 Open Out of char(8-bit) range value doesn't roll back, with uni-code ON. ===[Program Execution] 39992 Open proc_terminate() leaves children of child running 43784 Assigned escapeshellarg removes % from given string ===[Regexps related]== 44923 Open ereg functions are not unicode aware: provide wrapper functions in PCRE ===[Reproducible crash]=== 45107 Open setting ext_dir to ./ (and other ini settings) causes apache crash 47756 Open Segfault on HTML Purifier test suite ===[Scripting Engine problem]= 42194 Open $argc/$argv[] won't work when .php extension is assigned to php.exe 47154 Open Object properties unset after setting. ===[Session related]== 44860 Open session_encode() fails for php_binary serializer ===[SimpleXML related] 48601 Open xpath() returns FALSE for legitimate query ===[Strings related]== 45566 Open Strict comparision on $_SERVER values fail 47691 Verified strtr bug. Not replace unicode values from array, in binary string. ===[Unicode Engine related]=== 45087 Open Illegal or truncated character in input 47155 Open PHP 6.0 decodes base64 into incorrect uft-8 string 47164 Assigned uncomfortable (binary)char() append to binary string 48463 Open Strange unicode output for internal main constants ===[Unknown/Other Function]=== 48652 Assigned PHP6 Snaps - Invalid CRT parameters detected 48711 Open metaphone and sch, ch, gh
Re: [PHP-DEV] RFC: Boxing and Unboxing
On Thu, Jul 2, 2009 at 7:29 AM, Lukas Kahwe Smithm...@pooteeweet.org wrote: Hi, I recommend that you sign up on the wiki and publish your proposal on wiki.php.net/rfc regards, Lukas Added at http://wiki.php.net/rfc/boxingandunboxing -- Joshua Thompson Mechanical Engineer/Software Developer http://www.schmalls.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3: Is the use of {} to access string offsets deprecated?
On Jul 6, 2009, at 9:00 AM, Christian Schneider wrote:
The migration guide states that The use of {} to access string
offsets
is deprecated. Use [] instead. but the code in zend_compile.c is
commented out with #ifdef ilia_0.
What's the take on this? Will it be deprecated later or should that
part
be removed from the migration document?
It's been awhile but I once researched this, spoke with humans, and
determined this syntax is deprecated as of PHP 6 and documented[1] it
as such. However, that was almost three years ago so maybe the times
have changed.
Regards,
Philip
[1]
http://php.net/manual/en/language.types.string.php#language.types.string.substr
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] weak and strict type checking RFC
On 04.07.2009, at 22:08, Lukas Kahwe Smith wrote: On 04.07.2009, at 21:10, Paul Biggar paul.big...@gmail.com wrote: On Sat, Jul 4, 2009 at 7:12 PM, Lukas Kahwe Smithm...@pooteeweet.org wrote: I can't see the difference between your proposal and the conclusion I reached yesterday? (which was that there is a near consensus around strict checks by default, with casts allowed with some syntax). Well to me it Sounded like you wanted to Rely on Standard Type juggling and what i am proposing is more strict than that. More over i am Not convinced that strict should Be the Default. I don't know what you mean by standard type-juggling. Your proposal really does not outline what you want very much, just what you're against. As for strictness, if your proposal suggests that strict typing is the default, I cannot see where. I did Not specify what doesnt Match in the RFC. I will fix that omission on monday. I assumed it was clear that i tried to Provide Complete examples for what will Pass. So Passung a String with anything but 1 or 0 would Not Pass à Bool Type check. Ok, I have updated the RFC now with a table that shows that I expect to pass and fail. Its fairly late, so I might have missed something. In general what I am proposing is more lax than is_*() for the most part. Especially when it comes to checking strings. I do not understand why its suddenly so urgent to get this feature in(*), that people already speak about frustration over the process after just a few days. We dont need years and usually not months, but this is not the addition of some function. Its an extension to the language syntax, so I think its totally normal that we talk about this for at least a month. Though we do not of course need a daily exchange of 100 emails about this in this period. Obviously things can still be refined after the commit, but we should stuff give everybody a bit of time to let this stuff sink in before we do the initial commit. Also remember that plenty of people that contribute a fair bit to PHP internals do not read internals actively every week. So again a month isn't such a bad idea to have between the initial proposal and a commit of the feature. regards, Lukas Kahwe Smith m...@pooteeweet.org (*) even if the patch Ilia proposed doesn't break binary compatibility anymore, do we really want to start adding such stuff in 5.3.2? shouldn't we rather talk about finding a better release process (maybe build on top of recent developments in the version control world) that enables us to more quickly get x.y releases out without preventing bigger features like unicode from ever maturing? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] weak and strict type checking RFC
Hi Lukas, On Mon, Jul 6, 2009 at 11:03 PM, Lukas Kahwe Smithm...@pooteeweet.org wrote: Ok, I have updated the RFC now with a table that shows that I expect to pass and fail. Its fairly late, so I might have missed something. In general what I am proposing is more lax than is_*() for the most part. Especially when it comes to checking strings. I hope you have missed some things (or that they are typos) because otherwise a good chunk of this is plain lunacy. value string float int numeric scalar bool array 0 (integer) fail fail pass pass pass pass fail 1 (integer) fail pass pass pass pass pass fail 0 fails conversion to a float, but 1 and 12 succeed? 12 (double) fail pass pass pass pass fail fail It may seem that this is a good idea (12.0 passing the int check), but what if 12.0 is OK, but 144.0/12 does not (which might not be 12.0 due to floating point error)? '0' (string) pass fail fail pass pass pass fail '1' (string) pass fail fail pass pass pass fail '12' (string) pass pass pass pass pass fail fail Absolute lunacy. Please let this be a typo. '12.0' (string) pass pass pass pass pass fail fail '12.34' (string) pass pass fail pass pass fail fail As above. I think you need to present this information better. One advantage of Ilia's proposal is that it is very clear. It does two things: strong type check, or the same casts that currently exist. I think you need to say what changes you are introducing, and why they are introduced. The same flaw existed with my proposal: I dont think anyone wants a 3rd set of rules. I do not understand why its suddenly so urgent to get this feature in(*), that people already speak about frustration over the process after just a I think because this same issue has been going on for so long, and seem to be so very close now. This idea has been punted around in various forms and patches for years at this stage. few days. We dont need years and usually not months, but this is not the addition of some function. Its an extension to the language syntax, so I think its totally normal that we talk about this for at least a month. Well yes. But with near consensus, there is a danger of a 90% good-enough patch being derailed by new proposals, and I get the impression most people would be happier with the 90% patch. shouldn't we rather talk about finding a better release process (maybe build on top of recent developments in the version control world) that enables us to more quickly get x.y releases out without preventing bigger features like unicode from ever maturing? I've heard you mention this before. Please roll it into an RFC so we can think about it (FWIW, the idea that newer version control systems will somehow change everything makes little sense, so I think a lot of detail is required here). Thanks, Paul -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Type hinting/casting request for vote
Last week or so there was a fairly detailed discussion on the internals list regarding type hinting based on my original patch. Since then the patch has been revised to address the major concerns that were identified (breakage of binary compatibility) as well extended with additional functionality (object hint, type casting, reflection support, etc...). The final patch is available here: http://ilia.ws/patch/type_hint_53_v2.txt The test suit is available here: http://ia.gd/patch/type_hint_tests.tar.bz2 I would like to ask all developers to voice their opinions of whether it makes sense to add this to 5.3 or to throw it away (either one is fine btw). To keep the process simple flamewar free, please restrict yourself to +/- (1/0), next week monday I'll run a tally of the votes and based on the result we can determine how to proceed further. Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
2009/7/6 Ilia Alshanetsky i...@prohost.org: I would like to ask all developers to voice their opinions of whether it makes sense to add this to 5.3 or to throw it away (either one is fine btw). To keep the process simple flamewar free, please restrict yourself to +/- (1/0), next week monday I'll run a tally of the votes and based on the result we can determine how to proceed further. +1 -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
On Mon, Jul 6, 2009 at 8:52 PM, Ilia Alshanetskyi...@prohost.org wrote: Last week or so there was a fairly detailed discussion on the internals list regarding type hinting based on my original patch. Since then the patch has been revised to address the major concerns that were identified (breakage of binary compatibility) as well extended with additional functionality (object hint, type casting, reflection support, etc...). The final patch is available here: http://ilia.ws/patch/type_hint_53_v2.txt The test suit is available here: http://ia.gd/patch/type_hint_tests.tar.bz2 I would like to ask all developers to voice their opinions of whether it makes sense to add this to 5.3 or to throw it away (either one is fine btw). To keep the process simple flamewar free, please restrict yourself to +/- (1/0), next week monday I'll run a tally of the votes and based on the result we can determine how to proceed further. Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php +1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
+1 On Mon, Jul 6, 2009 at 10:42 PM, Eddie Drapkinoorza...@gmail.com wrote: On Mon, Jul 6, 2009 at 8:52 PM, Ilia Alshanetskyi...@prohost.org wrote: Last week or so there was a fairly detailed discussion on the internals list regarding type hinting based on my original patch. Since then the patch has been revised to address the major concerns that were identified (breakage of binary compatibility) as well extended with additional functionality (object hint, type casting, reflection support, etc...). The final patch is available here: http://ilia.ws/patch/type_hint_53_v2.txt The test suit is available here: http://ia.gd/patch/type_hint_tests.tar.bz2 I would like to ask all developers to voice their opinions of whether it makes sense to add this to 5.3 or to throw it away (either one is fine btw). To keep the process simple flamewar free, please restrict yourself to +/- (1/0), next week monday I'll run a tally of the votes and based on the result we can determine how to proceed further. Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php +1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Guilherme Blanco - Web Developer CBC - Certified Bindows Consultant Cell Phone: +55 (16) 9215-8480 MSN: guilhermebla...@hotmail.com URL: http://blog.bisna.com São Paulo - SP/Brazil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
On Tue, Jul 7, 2009 at 8:52 AM, Ilia Alshanetskyi...@prohost.org wrote: I would like to ask all developers to voice their opinions of whether it makes sense to add this to 5.3 or to throw it away (either one is fine btw). To keep the process simple flamewar free, please restrict yourself to +/- (1/0), next week monday I'll run a tally of the votes and based on the result we can determine how to proceed further. +1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP LLVM JIT-Compiler
Hi, I recently found the jit compiler for php (http://pecl.php.net/package/llvm). Are there any information avaible on this project? I just found that the student 'dropped out' of the project, but from then, nothing. Does anyone know which version of llvm this needs to compile (and which version of llvm-gcc?), and are there any further information on goals, todo plans etc? Maybe I could take up the work and try to improve that project, but for that i'd need some more information. I already know the talk and the slides of Nuno at llvm.org. Yours Cornelius -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
On Tue, Jul 7, 2009 at 4:52 AM, Ilia Alshanetskyi...@prohost.org wrote: Last week or so there was a fairly detailed discussion on the internals list regarding type hinting based on my original patch. Since then the patch has been revised to address the major concerns that were identified (breakage of binary compatibility) as well extended with additional functionality (object hint, type casting, reflection support, etc...). The final patch is available here: http://ilia.ws/patch/type_hint_53_v2.txt The test suit is available here: http://ia.gd/patch/type_hint_tests.tar.bz2 I would like to ask all developers to voice their opinions of whether it makes sense to add this to 5.3 or to throw it away (either one is fine btw). To keep the process simple flamewar free, please restrict yourself to +/- (1/0), next week monday I'll run a tally of the votes and based on the result we can determine how to proceed further. +1 -- Alexey Zakhlestin http://www.milkfarmsoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
