On Tue, 2013-01-22 at 09:39 -0600, nat...@starin.biz wrote:
> I am actually going to +1 this idea I thought about discussing it, but
> opted out of it because classes are most often in their own file and
> if you need to do some static binding you can do it at the end of the
> file after the class definition. However, I do believe this idea would
> make it easier to extend classes
How so?
> and make the code look much cleaner.
Thankfully that's subjective. Some people prefer explicit information
which can easily be read over magic, though.
> @Johannes In your example I'd say it would be ADBCE because I would
> say it should work like as if you had each one in it's own file
> autoloading them. (also I believe the function would be static)
In other words: It is called at completely arbitrary times. Which makes
reading code hard as well as making the implementation more complex
(dependency detection)
Mind that your order requires the engine to delay initialization of B
and C (and E) till D is found. And then go back. That's why I listed the
version with B in the end, that's a tiny bit simpler to implement, but
as hard to explain.
Now for a second game: What does the following script print?
<?php
echo "A";
class foo { static function __init() { echo "B"; } }
echo "C";
?>
ABC? ACB? BAC? I guess the later as the code next to A or C might depend
on the class already.
I hope you see the mess this creates, whereas we nowadays have a
solution which is properly defined and can easily be understood by
everybody, even by people coming from other languages and just trying to
understand the code which was put in front of them.
> One of the potential problems I can see is the visibility
> (public/private/protected) of the function as it'd likely need to be
> public because it could never be auto-executed if anything else.
Such things would be trivial to check during compilation phase.
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
