Re: parent_ctor()

Stanislav Malyshev wrote: > KK>> $o->$somevar). Limiting object do class-predeclard instance variables > KK>> may speed PHP - I haven't had a look at the implementation at all, > > No it won't. It would significantly slow down - you should check on any > property request that it's in the list of "allowed" properties. Why does it have to? I assume PHP4 objects are hashlike structures (again, not having looked at the source), so that they can have any number of slots at runtime, with any names. So I also assume that $o->somevar is a hash lookup as well. I wonder why the hash cannot be fully populated at $o = new Someclass time, containing all declared variables and functions. If that were the case, an error would be raised when later $o->invalid_slot returns NULL, instead of silently creating $o->invalid_slot. Why is that slow? Or is the mental model I have of PHP objects wrong? > And I > really won't trade object extendability concept and flexibility provided > by it to catch a couple of typing errors. As I already explained, you do not lose anything. $o->$somevar is really $o->epsilon[$somevar], with epsilon[] being really an empty name. So you can easily write $o->epsilon[$somevar] whenever you think $o->$somevar. As an added bonus, you can use array functions on $o->epislon[], which you cannot use on $o at all. You lose nothing, and even gain functionality. > KK>> and in any case it will make it easier to spot coding errors. > > Well, it is known that bondage-and-discipline languages are catching > errors earlier. Only problem it is that it's so painful to use them... You > choose your level of being disciplined and adjust. As I explained again above, this is not about B&D: Objects are not hashes. Hashes are hashes and that's why hash and array functions work on them. And unless my model of PHP4 object internals is completely off, this is not even necessarily slow. > KK>> quite uncontrolled manner (e.g. the constructor mess). At the > > I do not see any mess there. The thing is pretty simple, > AFAIK: "constructor is the method named after the class, or parent's > constructor on absence of that". ... or some nonconstructor method from any parent class which accidentally has the same name as the derived class and suddenly and unintendedly became the constructor. If this is not messy, I don't know what. And you cannot tell me that this is an intentional feature at all - this is what you get when you hack an extension (constructors) on top of an extensions (class syntax for hashes) without considering later use of the resulting system at all. You can hack even more rules on top of the PHP constructor rules (e.g. an inherited method can never become constructor, but must always be called by namespace operator), but this is not fixing bad design, it is adding uglyness on top of uglyness. > KK>> PHP _must_ become a fully featured programming language, > KK>> OO, references and all, because people are now using it > KK>> as such. > > Not so sure about this. There are real lot of FFPL's. PHP is not going to > compete C++ or Java or Smalltalk - we really can't win there. As I said, people are using PHP to do things fully featured programming languages do. PHP must grow to accomodate this. 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/