Re: parent_ctor()

From: Date: Tue, 18 Jul 2000 15:17:25 +0000
Subject: Re: parent_ctor()
References: 1  Groups: php.dev 
Request: Send a blank email to php-dev+get-24954@lists.php.net to get a copy of this message
Stanislav Malyshev wrote: > The goal is not to build 100% brick-wall-secure fully-fault-tolerant > correcting-errors-for-programmer language. The goal is the principle of least surprise, which is clearly violated here. > KK>> So is its default of allowing previously undeclared instance variables: > KK>> I will not detect an error in my own use of an imported superclass, > KK>> as PHP silently creates the new slot instead of complaining. > > Yes. Also, if you write "5" instead of "4" or "$i" instead of > "$j" PHP > won't detect this error too. PHP won't detect 100% of your errors, > otherwise we'd demand the money you get from writing programs :) I can detect errors in my own code. I can detect errors in foreign code, but with much more time investment. I cannot detect errors in foreign code (or in the interface between foreign code and my own code) once we have the Zend compiler and source code protection. That is simply because there will be no source to read - and we all know that documentation sucks. This (hidden or closed source of foreign components) and the policy of "allow everything" in the PHP language _will_ clash: There goes useable componentware. I tell you now, and I will tell you over and over again in 6 months, when the problem is acute and you feel the pain on this list, until you finally understand. > Sucks big time. You never know what you are doing when you have more than > 2 classes. Also, makes language harder to learn - yet another thing to > remember. And also looks godawful ugly - I hate __'s from C, don't want to > see them in PHP too. Then name it different, but give it a fixed name. Remember I told this list that this _will_ suck when constructors were introduced in the first place (and additionally, I told Thies in Hamburg, in a face to face meeting) and that I predicted that you will experience anomalies when you name constructors variably as they currently are. Now you have the spurious inheritance problem, and ridiculous complex inheritance rules (three rules instead of one) because ctors are jumping through the class-internal namespace like rabbits. > KK>> will not do this. Then at least make it so that the example I > KK>> cited will not break the language. > > Certainly it will. That will instantly break all scripts using > constructors. Read my mail again, please. I said, if you cannot use the one-rule-constructors ("Constructors are named __ctor()" or whatever fixed name you choose to please your sense of aestetics), then you should make it so that there will never be spurious inheritance (that is, in "class B extends A", where A contains a function named B(), A::B() cannot become a ctor in B). That's three-rule-constructors for your ("Constructors are named just as the class is named" "If a class has not ctor, the superclass ctor will be used" and a new, additional, third rule "An inherited function cannot become a ctor"). This won't break compat, and it will follow the principle of least surprise. And it is ugly, but then it will at least work. > KK>> - There should be a mode so that $o->bla = 17 raises an error > KK>> if $o->bla has not been declared before and that mode should > KK>> be the default. > > No way. This is going to break about 90% of scripts using PHP object > model. We could not call it PHP anymore then. And I really-really don't > see why we need it. See above. You get componentware, you get it probably without source because of the compiler and source code protection by encryption. You need a method to get feedback from the system that you are doing the right thing. Allow everything, and blind (no source) _will_ not work at all. > KK>> - There should be $super or super:: or whatever in order to > KK>> make superclass references in a normalized fashion. > > There is. Zeev just did it for you :) It's called parent:: Good. > KK>> - Ultimately PHP will need a namespace management mechanism for > KK>> classes similar to what XMLNS does with XML extensions. Or you > KK>> just rename classes on include (e.g. > > Yeah, yeah. Namespaces, domains, NIS, CORBA... Maybe in PHP 6. :) Even > Java doesn't have it, after all. :) PHP is not designed by a comitee, and not by a greedy corporation. That's why we move faster. Much, much faster. Again, talk to me in 6 or 12 month from now. Kristian -- Kristian Köhntopp, NetUSE AG Siemenswall, D-24107 Kiel Tel: +49 431 386 436 00, Fax: +49 431 386 435 99 Using PHP3? See our web development library at http://phplib.netuse.de/

« previous php.dev (#24954) next »