Re: parent_ctor()

KK>> If an object is not a hash, it should have properties that are KK>> different from a hash or it is jus a redundant feature. If I KK>> wanted runtime variable slots, I had used a hash in the first KK>> place, had I not? No. Runtime-definable object properties don't make it a hash (just like you having two eyes doesn't make you a cow, though it also has two eyes :) KK>> Perhaps I did not design the superclass at all, but used a component KK>> from the net and derived my own class from that. In that case the Then you should read documentation for that class before using it. If you see there method that has the same name as your class, change your class name (or, better, _first_ read interface definition of superclass, and _then_ start to program subclass). KK>> scenario I described will become increasingly likely, as the component KK>> I imported may have any number of public or undocumented private KK>> methods. The way PHP handles this situation is just unclean, and KK>> not fault-tolerant in such an environment. The goal is not to build 100% brick-wall-secure fully-fault-tolerant correcting-errors-for-programmer language. The goal is to build useful language. Concept of "constructor has the name of the class" is useful and proven. You should regard it as a tool and learn to use it. 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 :) KK>> - Fix the spurious constructor inheritance. The preferred way would KK>> be fixed constructor names such as __ctor(), but Zeev said he 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. 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. 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. 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:: 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. :) KK>> - and finally serialize references properly so that data structures KK>> are preserved across pages. Code it. I see no way to do it. If you do - show your code. If you don't - tough luck. KK>> and get rid of methodless objects (stdClass or whatever) and KK>> the "object" generic type. Make classes and types identical KK>> instead. Hope I did not forget something. OK, also I do not like stdClass too much, but what do you propose instead? We do need "anonymous" class and we do need methodless objects now (I don't know why object representation of IMAP letters was done, but it's there now - so stdClass probably is going to stay). KK>> Alternatively explain plausibly how PHP will scale to large KK>> and giant projects while you are not making the above changes. Just so. I do not believe your changes are *absolutely* necessary to PHP to get in project of any scale. They might be or not be _useful_ but claiming they are absolutely necessary is dangerously close to self-assertiveness. -- Stanislav Malyshev stas@zend.com +972-3-6139665