(ATTENTION) Pre-Beta

On Saturday 28 June 2003 10:40, Sterling Hughes wrote:

i've got a problem with sqlite.... ./configure --with-sqlite=shared make: /bin/sh /home/Allowee/PHP/pack/php5b1/libtool --silent --preserve-dup-deps --mode=compile gcc -I/home/Allowee/PHP/pack/php5b1/ext/sqlite/libsqlite/src -Iext/sqlite/ -I/home/Allowee/PHP/pack/php5b1/ext/sqlite/ -DPHP_ATOM_INC -I/home/Allowee/PHP/pack/php5b1/include -I/home/Allowee/PHP/pack/php5b1/main -I/home/Allowee/PHP/pack/php5b1 -I/home/Allowee/PHP/pack/php5b1/Zend -I/usr/include/libxml2 -I/usr/X11R6/include -I/usr/include/freetype2 -I/usr/include/mysql -I/home/Allowee/PHP/pack/php5b1/TSRM -g -O2 -prefer-pic -c /home/Allowee/PHP/pack/php5b1/ext/sqlite/libsqlite/src/parse.c -o ext/sqlite/libsqlite/src/parse.lo In file included from /home/Allowee/PHP/pack/php5b1/ext/sqlite/libsqlite/src/sqliteInt.h:16, from /home/wez/src/php/php4.3-cvs/ext/sqlite/libsqlite/src/parse.y:36: <- !!!!!!! /home/Allowee/PHP/pack/php5b1/ext/sqlite/libsqlite/src/config.h:1:50: /home/Allowee/PHP/pack/php5b1/config.h: No such file or directory <- !!!!!! make: *** [ext/sqlite/libsqlite/src/parse.lo] Fout 1 I don't seem to have /home/wez/ and I also don't have the config.h file in /home/Allowee/PHP/pack/php5b1 What should I do?? .: Allowee

Zitat von Sterling Hughes <sterling@bumblebury.com>:

Just something that doesn't have something to do with the pre-beta, but this HEAD generally: I think the register globals warning can safely be removed from the configure script now. Btw, compiles and tests fine. Jan.

URLs for the downloads have been changed: Source: http://downloads.php.net/sterling/ Win32 binaries: http://downloads.php.net/edink/ Edin On 28 Jun 2003, Sterling Hughes wrote:

Hi all! There are some troubles with PHP5-beta-1: With simple code like this: <? class Test { var $array_var = Array(); function test() { $this->array_var[0][0][0] = "test_method"; } function test_method($echo_var) { echo $echo_var; } } $test_obj = new test; $test_obj->array_var[0][0][0]("simple test"); //line 15 ?> I get "Fatal error: Method name must be a string in /www/index.php on line 15". But $test_obj->array_var[0][0][0] is definitely a string. Sorry if it's a known bug. --- WBR, Antony Dovgal aka tony2001 tony2001@phpclub.net

The

test failure was the result of <? being used in the test rather then <?php. A patch correcting this problem is now in the CVS. Ilia On June 28, 2003 04:40 am, Sterling Hughes wrote:

I've been doing some thinking about how to write error handling code that can run in both PHP 4 and PHP 5. Under the current situation, it looks like you have to resort to the lowest common denominator of PHP 4 to make error handling code that works under both versions. Here is a proposal for changing that: 1. Change built in functions to raise exceptions. There was a thread on this. This would let you do the standard modern error handling in PHP 5: try { db_connect ( 'foo' ); } catch (exception e) { } 2. Change php 5 to convert uncaught exceptions into standard PHP 4 style errors and pass them to the current error_handler. uncaught exceptions raised by the built in functions would be converted into exactly the same parameters to the error_handler that they would have triggered in PHP 4. This maintains backward compatibility without requiring any configuration parameters. Unmodified PHP 4 code running under PHP 5 would perform exactly the same as long as no try .. catch statements were used. This PHP 4 style code would still work the same in PHP 5 even when db_connect raises an exception: set_error_handler("myErrorHandler"); db_connect('foo'); 3. Change the suppress errors operator (@) to also suppresses exceptions. This is also required for backward compatibility, so that things like this still work the same way: @db_connect('foo'); 4. Change trigger_error to raise an exception. This allows PHP 4 compatible code to communicate with PHP 5 code via exceptions. For unmodified PHP 4 code, the uncaught exception would be changed back into a standard error_handler style error. Thus, the code would run the same under PHP 4. PHP 5 code could catch the exception. A good example of this would be calling a PHP 4/PHP 5 compatible library from either a PHP 4 or a PHP 5 program. The library can simply call trigger_error. Any caller can then handle the error in the way that is appropriate: function MultiVersionCompatableLibraryFunction() { if ($Problem) trigger_error("Message"); } function PHP4Caller() { set_error_handler("myErrorHandler"); MultiVersionCompatableLibraryFunction(); } function PHP5caller() { try { MultiVersionCompatableLibraryFunction(); } catch (exception e) { } } 5. Add a call_error_handler() function This function takes an exception as a parameter and converts it to a valid call on a PHP 4 style error_handler. call_error_handler($exceptionObj, $handlerName) The second parameter would default to the current error handler. This would be used for explicitly converting between the different error models: try { ... } catch (exception e) { call_error_handler($e); } This proposal is intended to give an intermediate solution for errorhandling during the transition from PHP 4 to PHP 5. Without this, the jump from using an error_handler to using exceptions is too harsh. As soon as you start using exceptions, you have to abandon PHP 4. This won't be realistic for libraries (such as smarty) that have to support the version of PHP that people are actually using. Without the capability to mix error models, library authors will have to delay using exceptions until the majority of installations are using PHP 5. With the described changes, library authors can migrate to an transitional solution that works with both PHP 4 and PHP 5. Comments? Is this possible? Am I missing something? This proposal is a bit half-baked, but I wanted to get it out as soon as I could.