Re: Well zeev, hereby:-)

Stanislav Malyshev wrote: > MK(>> That 'super' thig, do people want it? This basically would > MK(>> solve that 'circular reference' thing I had some time ago.. > > Could you please explain what is that 'super' thing? $super would be like $this, but referencing attributes and methods of the direct parent class of a class. Mostly, it would allow you to call methods that have been overridden, like ----- class a { function x() { print "x of a\n"; } } class b { function x() { print "preamble x of b\n"; $super->x(); print "postamble x of b\n"; } } ----- This is currently possible using namespaces as in a::x(), but that makes it necessary to denormalize the class relationship, as now the name of the superclass is coded into the subclass not only in the extends-statement, but also in many additional places. That propery of the current syntax makes changed in the class hierarchy overly hard. $super would have allowed you to chain constructors, had PHP given constructors fixed names instead of using the classname as constructor name, that is, you could have written ---- class b { function __ctor() { print "ctor of b\n"; $super->__ctor(); } } ----- Instead you get abominations as ----- class A { function A() { print "I am the ctor of a\n"; } function B() { print "I'm just an innocent function, not a ctor\n"; } } class B extends A { } $x = new b; ----- which prints ----- X-Powered-By: PHP/4.0.2-dev Content-type: text/html I'm just an innocent function, not a ctor ----- which is certainly not expected nor desired. In PHP3 and PHP4, the rule for ctors is currently "The name of the ctor function is the same as the name of the class". That would make it necessary to write a new ctor for each subclass, in order for the subclass to initalize itself properly. Had the ctor name been constant (e.g. __ctor), that wouldn't have been necessary, as the ctor would have been inherited with a proper name automatically. In PHP4, the ctor rule was amended with an exception: "If the superclass has a ctor, but the subclass has no function named just as the subclass, the superclass ctor is called despite having the wrong name." ----- kk@wwwx ~ $ Source/php3/php <?php class A { function A() { print "I am the ctor of a\n"; } } class B extends A { } $x = new B; X-Powered-By: PHP/3.0.17-dev Content-type: text/html kk@wwwx ~ $ ----- but ----- kk@wwwx ~ $ Source/php4/php <?php class A { function A() { print "I am the ctor of a\n"; } } class B extends A { } $x = new B; X-Powered-By: PHP/4.0.2-dev Content-type: text/html I am the ctor of a ----- So should it be fixed? Well, the object system in PHP currently is a mess: Classes are not types, they are just hashes with functions. Some people are currently using functionless objects as fancy array syntax, writing $o->a instead of $o["a"]. This very elegantly combines the ineffiency of objects with the lack of the ability to use array functions on them. Also, references are needed to deal properly with objects, and object networks (data structures made from objects, hashes, arrays and other container types). Additionally, ctors and dtors are handled in a suboptimal fashion or are even lacking completely. Although a mess, the current object system is a great improvement over the PHP3 non-object system: Even if not first class citizens, we do have references, and we do have an introspection API which is mostly complete, even if somewhat asystematically organized. I think the PHP object system should be fixed, and this can only be done with either breaking compatibility or by creating a second new object system with a different syntax. The fixed object system should be planned, not grown, and it should focus on dealing with componentware. That is, it should delay as many decisions as long as possible (into runtime, even call time, if possible) and it should be able to scry as many properties of an object and its class as possible at runtime. It should certainly require that instance variables are declared, because if you need $o->something for runtime-variable somethings, you may as well use $o->myhash["something"] instead. Making instance variables and instance methods fixed, declared properties of a class enables us to introduce protocols so that we can check for the presence of a predefined set of instance variables and functions with a single function call (if (conforms_to($someobj, "protocol")) and if (conforms_to(someclass, "protocol")) are true, if $someobj or someclass implement the instance vars and methods which belong to "protocol".) Proper support for serialization requires that we are able to save object networks, keeping references intact in order to keep our predefined data structures. Such serialization greatly simplifies may deeds, such as building RPC proxies, building generic interface builders, and other metaprograms. Also, second order serialization would also be useful, that is, serializing classes, for example by saving and loading the bytecode of their methods. That enables us to send not only objects, but even classes over the wire in a RPC call, or to easily deal with binary-only classes. All this requires planning and a roadmap, though, and BEFORE any additional mess is coded up and cast in stone. 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/