Hello everyone,
here is an updated list of things we need to do/discuss before beta 2.
I think we can live with many of these remaining until after beta 2. As long as we fix plenty of things (which we have), I think we should try to aim for another beta within 2 or 3 weeks.
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.
That should be happening today already.
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).
We'll add APIs for that.
- 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.
As I mentioned before, I don't really see a good solution here (for anything other than E_ERROR, at least). Since I don't think there's a solution in existence, it's low priority in my book (as in, I can live with seeing this remaining the way it is now).
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.
*sigh*
- 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.
Low priority in my book for similar reasons.
- 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).
We need to look into it - if it's doable, we'll do it.
- 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.
I don't see any reason for it to be longer than a hundred or two hundred lines of code - from the last time I saw it - it needs to be seriously cleaned up and written with the knowledge that it's going to be integrated in the engine before we integrate it.
- Include SPL array hooking into the engine (?!?)
I don't think we need this any longer, we have a very complete and clean solution now with the get/set dim hooks.
- 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>.
There's no need for the keyword 'var' to work - it's deprecated, and shouldn't be supported for new syntax.
I don't see a good reason to have the -> notation work with static elements. Differentiating between the two families (dynamic / static elements) at the syntax level makes good sense.
- Add support for 'this::<method>()', 'this::<property>'
? That's what you have self:: for.
and 'new this()' inside static methods.
I see no compelling reason to add 'new this()', but either way, if we do find such a reason, it will be 'new self()'.
Zeev
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
