Fw: [PHP-DEV] parent_ctor()

Whoops messed this up hehehe I should really stick to Linux + Pine Outlook, its just not me I sent this to Andi, while I had to CC: php-dev:> --caps ----- Original Message ----- From: Mathieu Kooiman <caps@gge.nl> To: Andi Gutmans <andi@zend.com> Sent: Monday, July 19, 1999 10:39 PM Subject: Re: [PHP-DEV] parent_ctor() > > The $__variable way I tried (I don't remember who introduced it) was fast > enough, it doesn't matter if what type it is > it would simply be considered a private variable because its prefixed with > __ > (perhaps use other prefix characters..) > > class test { > private var $test; // rewrite to _test__test in C > > function blaat () { > return $this->__test; // let php know we want to access a private > variable by __ > // if variable prefixed with '__' > we're actually looking for _test__test. > } > } > > $test 2 = new test; > > -- CaPS > > ----- Original Message ----- > From: Andi Gutmans <andi@zend.com> > To: <zeev@zend.com>; waldschrott <waldschrott@kiffen.de>; PHP Development > <php-dev@lists.php.net>; <kk@netuse.de> > Sent: Monday, July 17, 2000 7:10 PM > Subject: Re: [PHP-DEV] parent_ctor() > > > > At 20:10 17/07/2000 +0300, Zeev Suraski wrote: > > >At 19:57 17-07-00, waldschrott wrote: > > >>>saying 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). > > > > > >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 much > > >> 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. > > > > 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/ > > > > -- > > PHP Development Mailing List <http://www.php.net/> > > To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net > > For additional commands, e-mail: php-dev-help@lists.php.net > > To contact the list administrators, e-mail: php-list-admin@lists.php.net >