before beta2 (is alive again) :-)

----- Original Message ----- MB>From: "Marcus Börger" <marcus.boerger@t-online.de> MB>To: "Cristiano Duarte" <cunha17@uol.com.br> MB>Sent: Saturday, September 06, 2003 5:12 PM MB>Subject: Re: before beta 2 MB> MB> MB>Hello Cristiano, MB> MB>you should have asked on the list Sorry about that. It's on the list now. :-) CD>>Saturday, September 6, 2003, 9:51:55 PM, you wrote: CD>> Hi Marcus, CD>> What's the status of these patches ? MB>>> Hello 'internals', MB>>> MB>>> In no particular order these are the things i think should be done before MB>>> releasing the next php 5 beta version: MB>>> MB>>> - Include SPL (forach/array hooking). MB>Patch to be reviewed by Zeev and Andi. MB>http://marcus-boerger.de/php/ext/ze2/ze2-iterators-20030904.diff.txt MB>(since one month) No replies yet ? :-( MB>>> - Implement overloading as suggested by Sterling. MB>Discussion on details running. Ok. MB>>> - Typehinting with '= NULL' to allow NULL values as discussed MB>We know we must discuss this again. What needs to be discussed ? Typehinting works with NULL values (It's working for me), or am I wrong? MB>>> - Array and resource type hinting (patch at least for arrays is ready MB>>> and resources can easily be affed) MB>Patch is there, final decision needed (last time i asked it looked good for MB>yes). MB>http://marcus-boerger.de/php/ext/ze2/ze2-type-hints-20030722.diff.txt Has anyone against it ? I'm +1 MB>>> - Typehinting for return values? This may be usefule especially when MB>> working MB>>> with interfaces. MB>>> MB>>> - Fix __clone() visibility. When implementing singletons we must forbid MB>done. What was done ? The __clone() visibility or typehinting for return values? Maybe both ? MB>>> - Complete work on exceptions and find a solution on when to throw exceptions MB>>> and when to use errors. MB>>> I still do not see any BC problems with making try/catch blocks to convert MB>>> E_WARING, E_NOTICE & E_ERROR to exceptions (assumed the problemntaic E_ERRORS MB>>> are changed to E_CORE or such). Why no BC? Simply becuase using try/catch MB>>> with old libs and relying on there error capturing is an antilogy in itself. MB>>> Especially when thinking about the very limited capabilities in handling MB>>> errors the old way. MB>Exceptions seem to be ready for primetime though small changes like a new MB>interface throwable may be incorporated and we have c-level functions to MB>convert errors into exception which is needed for stors. Will be possible to do it transparently? I mean, a php.ini entry like: map_errors_to_exceptions_except_core_errors = true ;-) Or it has to be done programatically ? MB>>> - Discuss the package proposal and whether we want it or not. MB>All i can say right know is that it has friends. +1 MB>>> - Finally decide whether we want any other oo feature like aggregation, MB>No more features. MB>>> - Most parts of the language are case insensitive, however some parts are MB>>> not. For instance __construct, __clone,... MB>No changes. MB>>> - Move snprintf.c/spprintf.c into the engine. MB>Done by having zend_vspprintf() as pointer into php code. Ok. MB>>> - Fix static class members. MB>Should be fixed. Should or is fixed ? MB>>> - Do we want static methods to be overwritable? MB>>> php -r 'class t {static function x(){}}; class y {static function x(){}};' MB>Yes, we want it and it works. MB>>> - We need to be able to declare method flags from function table for classes MB>>> (static/public/protected/private/final). MB>Done. Ok. MB>>> - Plug some memleaks. MB>This is a never ending story, but we fixed several since beta 1 already :-) You're right and still there are so many to fix... :-( MB>-- MB>Best regards, MB> Marcus mailto:marcus.boerger@post.rwth-aachen.de Cristiano Duarte.