PHP Should Exploit Object Oriented Design More
Posted: Wed Jan 17, 2018 7:56 pm
To compete with other more sophisticated languages I believe that PHP should do more to support Object Oriented Design:
PHP strings are not objects. In many cases you must use non-OO functions, based upon classic C functions, to manipulate them: strlen($string) rather than $string->length, substr($string, ...) rather than $string->substr(...), and so on. The programmer must memorize a long list of special function names, and for each remember which parameter holds the reference to the string. For example: str_replace($search , $replace , $subject[,&$count]) rather than $string->replace($search , $replace , $subject[,&$count]).
This is an unfortunate consequence of the limited experience and objectives of Rasmus Lerdorf when he created the first implementation. Most early implementors of dynamic web-site content, including Rasmus, used PERL. I know, I was there and everybody around me was using PERL while I preferred to use C++ when I built my first dynamic web page in 1993. As stated in the PERL manual "Objects are merely Perl data structures (hashes, arrays, scalars, filehandles, etc.) that have been explicitly associated with a particular class." By contrast JavaScript, which was introduced in the same year that Rasmus donated the original PHP implementation, has been object oriented from the very beginning because it was designed originally as a lighter-weight competitor to Java. In Javascript you must write str.length not strlen(str).
PHP arrays are not objects. In particular PHP arrays do not implement the ArrayObject interface, the ArrayAccess interface, or the Iteration interface. So the programmer cannot do:
$arr = array();
... initialize the array
$arr->count(); // as oppose to count($arr)
$arr->offsetExists($i); // as opposed to array_key_exists($i, $arr)
This creates the same problem where the programmer must memorize a long list of special array_ functions and, once again, which of their parameters is the array since it is not always the first parameter.
Furthermore many of the basic functions originally implemented for arrays act on objects based upon the internal implementation of objects as arrays. The documentation of these functions does not reveal that they actually can be applied to objects, never mind that the action they take is counter-intuitive. As a consequence these functions can be used to violate the encapsulation rules defined for objects. In particular if the class does not implement the Iteration interface then foreach($object as $key => $value) by default iterates over all of the members of the class that are not private. Even if the class designer implements the Iteration interface so as to be able to exploit foreach this does not change the behavior of the basic array functions such as current, reset, next and so on, so there is no way a class designer can enforce the encapsulation rules. For example current($object) returns the value of the first field in the object, regardless of its defined privacy level.
The decision by the architects of PHP to continue down this road has resulted in the creation of 22 years of code that is almost impossible to debug because the basic language does not permit doing anything beyond limited syntax checking. If PHP supported even a little object-oriented design "php -l" could flag misspelled methods, and support encapsulation and polymorphism.
PHP strings are not objects. In many cases you must use non-OO functions, based upon classic C functions, to manipulate them: strlen($string) rather than $string->length, substr($string, ...) rather than $string->substr(...), and so on. The programmer must memorize a long list of special function names, and for each remember which parameter holds the reference to the string. For example: str_replace($search , $replace , $subject[,&$count]) rather than $string->replace($search , $replace , $subject[,&$count]).
This is an unfortunate consequence of the limited experience and objectives of Rasmus Lerdorf when he created the first implementation. Most early implementors of dynamic web-site content, including Rasmus, used PERL. I know, I was there and everybody around me was using PERL while I preferred to use C++ when I built my first dynamic web page in 1993. As stated in the PERL manual "Objects are merely Perl data structures (hashes, arrays, scalars, filehandles, etc.) that have been explicitly associated with a particular class." By contrast JavaScript, which was introduced in the same year that Rasmus donated the original PHP implementation, has been object oriented from the very beginning because it was designed originally as a lighter-weight competitor to Java. In Javascript you must write str.length not strlen(str).
PHP arrays are not objects. In particular PHP arrays do not implement the ArrayObject interface, the ArrayAccess interface, or the Iteration interface. So the programmer cannot do:
$arr = array();
... initialize the array
$arr->count(); // as oppose to count($arr)
$arr->offsetExists($i); // as opposed to array_key_exists($i, $arr)
This creates the same problem where the programmer must memorize a long list of special array_ functions and, once again, which of their parameters is the array since it is not always the first parameter.
Furthermore many of the basic functions originally implemented for arrays act on objects based upon the internal implementation of objects as arrays. The documentation of these functions does not reveal that they actually can be applied to objects, never mind that the action they take is counter-intuitive. As a consequence these functions can be used to violate the encapsulation rules defined for objects. In particular if the class does not implement the Iteration interface then foreach($object as $key => $value) by default iterates over all of the members of the class that are not private. Even if the class designer implements the Iteration interface so as to be able to exploit foreach this does not change the behavior of the basic array functions such as current, reset, next and so on, so there is no way a class designer can enforce the encapsulation rules. For example current($object) returns the value of the first field in the object, regardless of its defined privacy level.
The decision by the architects of PHP to continue down this road has resulted in the creation of 22 years of code that is almost impossible to debug because the basic language does not permit doing anything beyond limited syntax checking. If PHP supported even a little object-oriented design "php -l" could flag misspelled methods, and support encapsulation and polymorphism.