Re: parent_ctor()

KK>> I wonder why the hash cannot be fully populated at $o = new Someclass KK>> time, containing all declared variables and functions. If that were Ah, it can. Then indeed it won't slow down that much, but I really don't see why free-declared properties are so bothersome to you. Also, it would slow you down in the meaning that you'll need always to declare properties even though they are used only in some rare situations. PHP paradigm is to be non-disciplined language, that is what allows you rapid development. I know that enterprise development and rapid development require conflicting paradigms, so you should choose. KK>> > And I KK>> > really won't trade object extendability concept and flexibility provided KK>> > by it to catch a couple of typing errors. KK>> KK>> As I already explained, you do not lose anything. $o->$somevar KK>> is really $o->epsilon[$somevar], with epsilon[] being really an KK>> empty name. So you can easily write $o->epsilon[$somevar] whenever Well, then you as well could write: if(defined($class->$var)) { $class->$var = 1; } else { print "Error: undefined property $var"; } Again, PHP is non-disciplined language, and people like it for that. KK>> you think $o->$somevar. As an added bonus, you can use array KK>> functions on $o->epislon[], which you cannot use on $o at all. KK>> You lose nothing, and even gain functionality. No I don't. I lose free-ness of the lanugages. We already were there with C++ and Java. 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? Why don't you want to use SQL queries on GIF image, for example? KK>> ... or some nonconstructor method from any parent class which KK>> accidentally has the same name as the derived class and suddenly KK>> and unintendedly became the constructor. Well, so you made a mistake if you did that. Solution is simple: always define constructors. That's what you get for using runtime-bound language. PHP shouldn't babysit you. That's you who made a mess, not PHP. There are a lot of ways to shoot yourself in the foot with PHP, but it's not PHP to blame, it's you. 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. If you though about class hierarcy before touching keyboard, you'd never name non-constructor method after the class name. Just for clearness, if not else. KK>> You can hack even more rules on top of the PHP constructor rules KK>> (e.g. an inherited method can never become constructor, but must KK>> always be called by namespace operator), but this is not fixing KK>> bad design, it is adding uglyness on top of uglyness. Yes, PHP is not fixing your bad design. That's your work. KK>> As I said, people are using PHP to do things fully featured KK>> programming languages do. PHP must grow to accomodate this. 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 :) OK, again: what's your proposal? -- Stanislav Malyshev stas@zend.com +972-3-6139665