In my opinion beta 1 should be labeled as a beta. The fact that we are fixing a few features doesn't mean it's alpha. I know what the definition of alpha is but in real life most beta's do end up having quite a few code changes before release.
I agree that we should try and feature freeze as much as possible right now. I'd like to see PHP 5 out before the 6-9 month period Sterling mentioned. I think we can probably do it within about 4 months if we don't mess with the code too much and listen to the feedback of people who are starting to play around with it.
In my opinion, half the stuff listed by Marcus should wait for PHP 5.1 (which can be released very quickly after PHP 5):
- Include SPL (forach/array hooking) (although we can discuss it and re-evaluate this once we finalize what we want).
- Typehinting for return values? This may be useful especially when working
with interfaces. (Not sure about this but I think it can wait).
- Complete work on exceptions and find a solution on when to throw exceptions
and when to use errors. (as I said I think we should keep it purely in user-land until we see how people end up using exceptions and we get enough feedback. I haven't heard any ideas here which are rock solid yet.).
- Discuss the package proposal and whether we want it or not. (Don't think this is for PHP 5).
- Finally decide whether we want any other oo feature like aggregation,
delegation or what ever. (-1 too)
I didn't understand the following: - We need to be able to declare method flags from function table for classes (static/public/protected/private/final).
The rest of the stuff (which are mainly bug fixes) should be addressed.
Andi
At 02:28 AM 30/6/2003 +0200, Marcus Börger wrote:
Hello 'internals',
In no particular order these are the things i think should be done before releasing the next php 5 beta version:
- Include SPL (forach/array hooking).
- Implement overloading as suggested by Sterling.
- Typehinting with '= NULL' to allow NULL values as discussed
- Array and resource type hinting (patch at least for arrays is ready and resources can easily be affed)
- Typehinting for return values? This may be usefule especially when working with interfaces.
- Fix __clone() visibility. When implementing singletons we must forbid calling
__clone() by making it private (private function __clone() is the same to
singletons as private function __construct() to factories). Also the clone
mechanism must ensure the new object has all properties defined in the class.
The current implementation doesn't do so what contradicts the inheritance
model. The following example show both errors:
php -r 'class t {var $x; private function __clone() {} }; $a = new t; $b = $a->__clone(); var_dump($a);var_dump($b);'
object(t)#1 (1) {
["x"]=>
NULL
}
object(t)#2 (0) {
}
- Complete work on exceptions and find a solution on when to throw exceptions
and when to use errors.
I still do not see any BC problems with making try/catch blocks to convert
E_WARING, E_NOTICE & E_ERROR to exceptions (assumed the problemntaic E_ERRORS
are changed to E_CORE or such). Why no BC? Simply becuase using try/catch
with old libs and relying on there error capturing is an antilogy in itself.
Especially when thinking about the very limited capabilities in handling
errors the old way.
- Discuss the package proposal and whether we want it or not. We saw that
namespaces didn't really fit in our needs and that they are very problematic.
To tell the truth some here are sure they can't be implemented correct. The
ones thinking the they would obviosly had another idea of them. So let us not
make the same mistake again and make instead sure we are all talking about
the same thing in the same language.
- Finally decide whether we want any other oo feature like aggregation, delegation or what ever. From my point of view they are nice but not necessary and will cause more development trouble then they will bring advantage to the user. So don't lets spend any more efforts in this area.
- Most parts of the language are case insensitive, however some parts are not. For instance __construct, __clone,...
- Move snprintf.c/spprintf.c into the engine.
- Fix static class members. If the are public they need to be accessible from
outside the class. If they have an initial value this value should be used
and the keyword var should be working as well.
php -r 'class t { static public $p = "x";}; $t = new t; var_dump($t->p);'
php -r 'class t { static var $p = "x";}; $t = new t; var_dump($t->p);'
php -r 'class t { static public $p = "x";}; echo $t::p;'
To make this clear: $t->p would add a dynamic propery to instance t while we
want to access the static property p which can only be achieved by a
different notation which should be <class>'::'<static_member>.
- Do we want static methods to be overwritable? php -r 'class t {static function x(){}}; class y {static function x(){}};'
- We need to be able to declare method flags from function table for classes (static/public/protected/private/final).
- Plug some memleaks.
-- Best regards, Marcus mailto:[EMAIL PROTECTED]
-- 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
