Re: parent_ctor()

Stanislav Malyshev wrote: > KK>> As I explained again above, this is not about B&D: Objects are > KK>> not hashes. Hashes are hashes and that's why hash and array functions > KK>> work on them. And unless my model of PHP4 object internals is > KK>> completely off, this is not even necessarily slow. > > Why would ou want to use array function on object? When you treat an object as a hash, you should be able to use hash functions on it. Otherwise you are just combining disadvantages of both. If an object is not a hash, it should have properties that are different from a hash or it is jus a redundant feature. If I wanted runtime variable slots, I had used a hash in the first place, had I not? > KK>> [ inherited constructors which were not intended to be ctors ] > KK>> If this is not messy, I don't know what. And you cannot tell me > KK>> that this is an intentional feature at all - this is what you > KK>> get when you hack an extension (constructors) on top of an > KK>> extensions (class syntax for hashes) without considering later > KK>> use of the resulting system at all. > > No, that's what you get when you hack class structure without previously > designing it. Perhaps I did not design the superclass at all, but used a component from the net and derived my own class from that. In that case the scenario I described will become increasingly likely, as the component I imported may have any number of public or undocumented private methods. The way PHP handles this situation is just unclean, and not fault-tolerant in such an environment. So is its default of allowing previously undeclared instance variables: I will not detect an error in my own use of an imported superclass, as PHP silently creates the new slot instead of complaining. > Not at all. If someone is using PHP in real-time environment, that doesn't > mean we should rush and rewrite all PHP to adhere to real-time > requirements. That only says we are so good that we made PHP be real-time > without even thinking about it :) You made PHP a language with a halfway decent object system accidentally and now people are using these features. You'd better fix the other half before people start using the feature in earnest, or there will be problems of all kinds. > OK, again: what's your proposal? Fix the object system: - Fix the spurious constructor inheritance. The preferred way would be fixed constructor names such as __ctor(), but Zeev said he will not do this. Then at least make it so that the example I cited will not break the language. - There should be a mode so that $o->bla = 17 raises an error if $o->bla has not been declared before and that mode should be the default. - There should be $super or super:: or whatever in order to make superclass references in a normalized fashion. - Ultimately PHP will need a namespace management mechanism for classes similar to what XMLNS does with XML extensions. Or you just rename classes on include (e.g. include("tobias/mail.inc") class Mail as TMail; include("kris/mail.inc") class Mail as KMail; - and finally serialize references properly so that data structures are preserved across pages. and get rid of methodless objects (stdClass or whatever) and the "object" generic type. Make classes and types identical instead. Hope I did not forget something. Alternatively explain plausibly how PHP will scale to large and giant projects while you are not making the above changes. 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/