You forgot these:
http://bugs.php.net/search.php?search_for=&boolean=0&limit=All&order_by=id&direction=DESC&cmd=display&status=Open&php_os=&phpver=5&assign=&author_email=&bug_age=0
--Jani
On Sun, 20 Jul 2003, Marcus B� rger wrote:
>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:[EMAIL PROTECTED]
>
>
>
--
https://www.paypal.com/xclick/[EMAIL PROTECTED]&no_note=1&tax=0¤cy_code=EUR
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
