Re: parent_ctor()

At 16:19 18/07/2000 +0200, Kristian Köhntopp wrote:

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.

I really don't think this is such a big deal. What is wrong with the way it is now (similar to C++)? If you want us to add code so that parent functions can't "by mistake" slip in as constructors this is probably quite doable without having to take the __ctor() approach.

- 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.

Well we'd be breaking backwards compatibility big time. And the thing people love about PHP is being able to define variables on the fly and not having errors raised on every second line.

- There should be $super or super:: or whatever in order to make superclass references in a normalized fashion.

Zeev implemented parent:: a couple of days ago.

- 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;

Uhm, I don't quite understand what you want here. At compile-time you don't actually parse that include() file, so you don't know there's a Mail class in there so you can't rename it to TMail.

- and finally serialize references properly so that data structures are preserved across pages.

This has nothing to do with the Zend Engine IMO. You have to make the PHP serializer smarter.

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.

I guess I'm missing what you mean here. What is so bad about methodless objects? It exists in just about any OOP language. Andi --- Andi Gutmans <andi@zend.com> http://www.zend.com/