PHP 4.0 Bug #5377 Updated: Using :: on instance functions / future devolpment of PHP

From: Date: Thu, 06 Jul 2000 12:56:16 +0000
Subject: PHP 4.0 Bug #5377 Updated: Using :: on instance functions / future devolpment of PHP
Groups: php.dev 
Request: Send a blank email to php-dev+get-23561@lists.php.net to get a copy of this message
ID: 5377 User Update by: waldschrott@kiffen.de Status: Open Bug Type: Feature/Change Request Description: Using :: on instance functions / future devolpment of PHP ////Taken again from a newer posting of Kristian (kk@netuse.de) Some definitions for a language that is not quite like Zend/PHP4: Let C by a class, let $o = new C; be an object, an instance of C. The object $o have some instance variables named o1, o2, o3. At the moment, these are being addressed in PHP using the following arrow syntax: $o->o1 = "something"; $o->o2 = 17; ... The class C could have some class variables c1, c2, c3. These are variables which belong to the class, not the object and are shared by all instances of C. One could probably write $C::c1 = "something"; $C::c2 = 17; ... to address these values. Using C::c1 = "something"; ... would be a bad idea because PHP relies on the $ prefix for variable names to do string interpolation. To make things consistent, the instance methods im1, im2, im3 and so on of $o are being called using $o->im1(); ... and so on. Thus, writing C::cm1(); ... to call the class methods as we currently do in PHP would be inconsistent. It should be orthogonal, thus the syntax should me $C::cm1(); ... to call class methods, if possible. Now, what are class methods and what are class variables? A class method is a method that can be called without having an instance of that class. This method should not be able to use instance methods, as there is no instance. It should not be able to use instance variables, for the same reason. It may be possible to use "$this" internally in a class method to refer to other class methods of the same class, and to refer to other class variables of that class. This would be useful, as there will be less references to the hardcoded classname in the code - the class name should be used only in one place, the class definition "class <name>" or "class <name> extends <name'>". I assume this is implemented by making a class an object, too (So of what class is the class object? Metaclass! So is Metaclass, terminating the recursion. Have a look at the Smalltalk object model for detailed information - this is an bytecode interpreted single inheritance language just as PHP4, so it should be adequate.) If all classes are instances of Metaclass, they would inherit a number of methods from Metaclass, and these methods would be what is currently available as Zend functions such as get_class() and get_parent_class. Even new could be a method of Metaclass, leading to constructs such as $o = $C::new(); but this is for the OOP stasi only. It shows how orthogonal things can be in such a model. There is no need at all for class methods and class variables, PHP is already turing complete. Now that you have references, you can emulate class methods and class variables for any given class C by manually creating a class C_Keeper, of which you create only a single instance, and which you use to implement all class methods and variables. Having this as part of the language makes certain things easier to code. If you are going to modify the PHP object model, you should stop now, though, and think hard. You should also read up on Smalltalk and on Objective-C as these are the object models that make the most sense in a PHP context. You should have a look at C++, also, to see an object model that is overly complex, fails to deliver some critical features, and generally sucks. If you are interested, I can provide you with some information on that, but I won't rant about C++ unasked here. Only after having decided on a sensible object model for PHP we should go and implement more, to avoid confusion in the language. Full Bug description available at: http://bugs.php.net/?id=5377

« previous php.dev (#23561) next »