Re: parent_ctor()
| From: | Andi Gutmans | Date: | Mon, 17 Jul 2000 17:10:21 +0000 |
| Subject: | Re: parent_ctor() | ||
| References: | 1 2 3 | Groups: | php.dev |
| Request: | Send a blank email to php-dev+get-24799@lists.php.net to get a copy of this message | ||
At 20:10 17/07/2000 +0300, Zeev Suraski wrote:
At 19:57 17-07-00, waldschrott wrote:Yes but we do agree on two main things. First of all we both would like to see support for $foo->blah()->barbara Secondly, if possible, we both don't mind supporting private members. The biggest problem here is that we haven't come up with a fast solution for this. Andi --- Andi Gutmans <andi@zend.com> http://www.zend.com/Well, if you summarize my entire view and reasoning on this issue, then yes, clearly I'm against it. The price to pay is high, it would benefit a very small number of very-large-scale projects, which aren't common to PHP or the Web in general, and goes against the theme of PHP. Weighting everything together - it's a clear 'no'. I don't see how it makes big projects impossible. In fact, I know for a fact it doesn't, because quite huge projects use PHP successfully, and are completely maintainable (and maintained). As I see it, PHP targets big projects, BUT only if it doesn't hurt its much muchsaying that it won't benefit at all - perhaps Kristian would find it indispensable for PHPlib, but the vast majority of Web developers would not. And with all due respect to PHPlib, we won't change the PHP language theme and concept to be a better framework for PHPlib.You´re to negative. I´m sure there are numerous advanced apps which could benefit from *some* improvements and I do respect Kristians involvement trying to influence PHPs development in a way PHP would profit of. (He noticed what would make sense and why).wider > and common audience, of medium and small scale projects. Hm, I´ve been to dramatic, sure. But it´s much easier to maintain (def maintain: bug fix, exetend, transform apps) OO code in my opition.And to that extent, PHP's OO support is quite useful and usable. If you're willing to pay the performance price, you're invited to use it.Offering some extended functionality witht PHP4 and saying that it´s a language which should in every part be easy to learn and the main target audience is the vast majority of unexperienced html constructors which should be enabled to add same dynamic functions will close the way to PHP5 or later versions I think. PHP could become more feature rich, regarding functions and extensions, not more not less. I understand Kristian, I´ve stumbled into some problems too, I could work around but at some points only the ugly way. Andi´s latest post was a lot more positive.Andi and I don't completely see eye-to-eye on all of the issues. However, the fact that we're not going to make any downwards incompatible changes, and that we're not going to introduce a whole new object system, are given, and we agree on that completely. If we add any new functionality to the PHP object model (e.g. private methods), it's going to build on top of the existing object model, and not replace it.