Updated PHP 5 ToDo

>Hello everyone, > >here is an updated list of things we need to do/discuss before beta 2. > > >High priority: > >- Completely force a derived class now to implement the same amount of > parameters with the same typehints as the inherited one. When it comes > to typehints theory allows to provide same or parent types but that would > be much harder to implement so only allowing the same type is just easier. > > We also don't have a way to specify typehints and param amount for functions > declared at c-level. Further more we are not able to specify access type of > a method declared at c-level (static/public/protected/private/final). > >- 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 error capturing is an antilogy in itself. > Especially when thinking about the very limited capabilities in handling > errors the old way. > > Add an opcode to be able to see whether a try/catch is active. This could > possibly also allow to check which exceptions will get catched. Having this > we could finally convert uncaught exceptions to errors. > > Discuss about adding 'thorws' to a method declaration and a flag for c-level > functions so that the compiler can emit an error when such a method is used > without try/catch. > >- 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 at > all. The ones thinking they could be done obviosly had another idea of them. > So let us not make the same mistake again and instead make sure we are all > talking about the same thing in the same language. > >- Add a third shutdown phase which can be used by extensions like ext/session > to do work that must be done before objects and globals get destroyed. Also > ensure that variable destrcution is done in two steps first all objects then > the globals because an object may rely on a global var (yes ppl will do so). > >- Plug some memleaks. > > > > >Easy (patch ready): > >- Array and resource type hinting (patch at least for arrays is ready > and resources can easily be affed). > >- Include SPL forach hooking into the engine. > Renaming the files to 'Zend_whatever' doesn't really make a difference. > Maybe the patch is a bit lengthy but the biggest part of it is a function > that allows to very effectively call methods - pretty much faster then the > current solution. So it would also speed up other things. > > > > >More things to do: > >- Include SPL array hooking into the engine (?!?) > > The current array hooking implementation doesn't allow user defined objects > to hook into array overloading with methods like the flexible solutions spl > provides. Do we still want this a language feature or as a non default option > provided via an extension? > > Maybe the the cleanest way would be to directly hook into the engine's array > overloading facilities and check whether a certain interface is implemented > and then call the methods of that interface instead of using the default > implementation. > >- Array overloading misses support for 'unset($obj[$idx]);' > >- Typehinting with '= NULL' to allow NULL values as discussed > >- Typehinting for return values? This may be useful especially when working > with interfaces. > >- 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 they 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>. > >- Add support for 'this::<method>()', 'this::<property>' and 'new this()' > inside static methods. > >- Add __sleep(), __wakeup() as object handlers. > > > >Best regards, > Marcus mailto:marcus.boerger@post.rwth-aachen.de > > >

> Hello everyone, > > here is an updated list of things we need to do/discuss before beta 2. > > > High priority: > > - Completely force a derived class now to implement the same amount of > parameters with the same typehints as the inherited one. When it > comes > to typehints theory allows to provide same or parent types but that > would > be much harder to implement so only allowing the same type is just > easier. > > We also don't have a way to specify typehints and param amount for > functions > declared at c-level. Further more we are not able to specify access > type of > a method declared at c-level (static/public/protected/private/final).

> > - 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 error capturing is an antilogy in > itself. > Especially when thinking about the very limited capabilities in > handling > errors the old way.

> Discuss about adding 'thorws' to a method declaration and a flag for > c-level > functions so that the compiler can emit an error when such a method > is used > without try/catch.

> Hello everyone, > > here is an updated list of things we need to do/discuss before beta 2.

>Hello everyone, > >here is an updated list of things we need to do/discuss before beta 2.

>High priority: > >- Completely force a derived class now to implement the same amount of > parameters with the same typehints as the inherited one. When it comes > to typehints theory allows to provide same or parent types but that would > be much harder to implement so only allowing the same type is just easier.

> We also don't have a way to specify typehints and param amount for > functions > declared at c-level. Further more we are not able to specify access type of > a method declared at c-level (static/public/protected/private/final).

>- 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 error capturing is an antilogy in itself. > Especially when thinking about the very limited capabilities in handling > errors the old way. > > Add an opcode to be able to see whether a try/catch is active. This could > possibly also allow to check which exceptions will get catched. Having > this > we could finally convert uncaught exceptions to errors.

> Discuss about adding 'thorws' to a method declaration and a flag for > c-level > functions so that the compiler can emit an error when such a method is > used > without try/catch.

>- 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 at > all. The ones thinking they could be done obviosly had another idea of > them. > So let us not make the same mistake again and instead make sure we are all > talking about the same thing in the same language.

>- Add a third shutdown phase which can be used by extensions like ext/session > to do work that must be done before objects and globals get destroyed. Also > ensure that variable destrcution is done in two steps first all objects > then > the globals because an object may rely on a global var (yes ppl will do > so).

>- Include SPL forach hooking into the engine. > Renaming the files to 'Zend_whatever' doesn't really make a difference. > Maybe the patch is a bit lengthy but the biggest part of it is a function > that allows to very effectively call methods - pretty much faster then the > current solution. So it would also speed up other things.

>- Include SPL array hooking into the engine (?!?)

>- Fix static class members. If they 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>.

>- Add support for 'this::<method>()', 'this::<property>'

> and 'new this()' > inside static methods.

> Hello everyone, > > here is an updated list of things we need to do/discuss before beta 2.