On Fri, 2006-10-20 at 23:05 +0200, Marcus Boerger wrote: > Hello Lukas, > > nonsense, there was no OO in PHP 4. We only had arrays with somehow
I think you're leaning too much on a specific definition of OO that isn't necessarily shared by the rest of the cosmos, especially the millions of PHP4 developers that decided it was good enough, and chose it over the spectrum of alternatives. > attached methods. No static, no abstract, no visibiity, no nothing. Then PHP > 5.0 was done in a very bad rush and we made mistakes as we didn'T have time > to test it. Thus we had to quickly deliver 5.1. And even 5.1 is not being > used. Now we must stay with the errors/mistakes we did in that rush forever? But it does have inheritance, polymorphism, and a crude ability to provide a namespace wrapper to functions. > Speaking of "abstract static" functions, they make absolutely no sonse from > a theoretical point of view (*). Actually it even defeats the purpose. As a > compromise we allowed static abstract in interfaces. However i am not quite > sure our own rules are correctly there. The compromise was fine as wecould > enforcesignature inheritance for static methods. So in PHP we could even get > more expression power than in other languages. > > One question I like to give to everyonedropping rules out of PHP. If you > want OO without rules, why do you use inheritance after all? Ever considered > OO might be the wrong programming paradigm for you :-) Because inheritance is probably the single most important feature of OO. Almost everything else is sugar. > Technically at the moment we have no problem whether weenforce inheritance > rules or not. We only need them for magic functions: __*(). > > That said I can only repeat here what I said earlier on IRC. Lets do things > right and make the more complex OO rules as E_STRICT and create new severity > level E_DEPRECATED. E_STRICT will then only be used for 'pedantic' OO rules > while E_DEPRECATED will be used for stuff that is considered bad practize > and that might be removed in later versions. For me later would best be a > rule like earliest two minor versions later. If we do so we create a > situation wher I hope everyonecan get happy. All users can be informed about > upcoming changes using E_DEPRECATED and the OO supporters enable E_STRICT > while the dynamic fraction disables it. Last but not least i would like to > see 5.2 delayed for an additional month to get that change into and discuss > which rules are to be changed rather than makingone or the other fraction > pretty unhappy or increase chaos. > > best regards > marcus > > (*) But we are PHP and those theoretical language developments and common > understanding do not always apply - as some here know better...Sometimes > for the good and sometimes it just confuses people (Where good means it > allows faster hacking). Do not get me wrong here, PHP is nice and one of > it's big plus is its very dynamicnature. But this nature also comes with > a lot of problems that keep a lot of potential users away from it as well > as it limits ourselves. Maybe not adopting strict OO will keep a lot of potential users away, but judging from the speed of PHP5's adoption, you're keeping a lot more PHP4 users away by tightening the noose around our necks. Cheers, Rob. -- .------------------------------------------------------------. | InterJinn Application Framework - http://www.interjinn.com | :------------------------------------------------------------: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `------------------------------------------------------------' -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
