PHP Developers Network

A community of PHP developers offering assistance, advice, discussion, and friendship.
 
Loading
It is currently Sun May 20, 2018 10:26 pm

All times are UTC - 5 hours




Post new topic Reply to topic  [ 4 posts ] 

Should PHP Support Object Oriented Design?
Encapsulation (hide private and protected from internal funcs) 20%  20%  [ 1 ]
Polymorphism (depending upon parameter types) 20%  20%  [ 1 ]
flag misspelled class members 20%  20%  [ 1 ]
string (e.g. support the same methods as JavaScript string) 20%  20%  [ 1 ]
array (support ArrayObject, ArrayAccess, Iteration 20%  20%  [ 1 ]
Total votes : 5
Author Message
PostPosted: Wed Jan 17, 2018 8:56 pm 
Offline
Forum Commoner

Joined: Mon Mar 08, 2010 8:40 am
Posts: 41
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.


Top
 Profile  
 
PostPosted: Thu Jan 18, 2018 7:44 pm 
Offline
Site Administrator
User avatar

Joined: Wed Aug 25, 2004 7:54 pm
Posts: 13555
Location: New York, NY, US
Yes, we know the trade-offs that PHP has made. Many of your points are reasonable. However there are two rebuttals:

1. PHP focuses on ease of implementation. You may not like that style of "worse is better" programming, but there are many other programming languages so pick one that suits you and let those who like this style use PHP. No one if forcing you to use PHP.

2. Pure OO style programming is not a perfect solution. Many modern language (Ruby, Python, Javascript) diverge widely from a classic OO style to meet specific goals and support other styles of programming. No one says OO isn't good -- but it's not perfect and modern language innovation shows that.

_________________
(#10850)


Top
 Profile  
 
PostPosted: Thu Jan 18, 2018 9:44 pm 
Offline
Forum Commoner

Joined: Mon Mar 08, 2010 8:40 am
Posts: 41
Christopher wrote:
No one if forcing you to use PHP.


If I am running my own server, true. But if I am a guest on a commercial web server I am stuck with whatever they support. In particular if I had the choice I would use Java SE or C#/.NET. But they are only available on premium service sites which I cannot afford for a hobby site, even if that hobby site has over a gigabyte of scripts and two gigabytes of MySQL database.

Furthermore I do not suggest any change or even deprecation of the conventional library, only that:
  • The existing "flat" interface is hard to learn because there are too many function names with unpredictable parameter ordering. I have been programming in PHP for 15 years and I still will not use any of these functions without first calling up the documentation from the manual to ensure that I have the parameters in the right order.
  • The lack of encapsulation and polymorphism prevents catching some common errors even at execution time.
I have encountered specific problems:
  • I have a number of container classes which implement all of the PHP interfaces provided for emulating the behavior of an array. But I still have to check at almost every instance whether I have called a function with an array or an instance of a container because I have to use the object-oriented methods with the container but the classic functions with an array. For example to get the first element of the container I must call $container->rewind() whereas on the array I must call reset($array). But PHP does not warn me about this because it is entirely legal to call reset on an object, but it returns something that I find non-intuitive: the value of the first attribute in the class, which is generally some private management field and is never the value of the first element in the container.
  • I have an object whose logical external behavior is that of a string, but I have to access that behavior through class methods rather than the intuitive interface of the PHP string. Admittedly that is a problem with most OO languages, whose architects felt that they had the right to exclusive use of the operators.


Top
 Profile  
 
PostPosted: Thu Jan 18, 2018 11:08 pm 
Offline
Site Administrator
User avatar

Joined: Wed Aug 25, 2004 7:54 pm
Posts: 13555
Location: New York, NY, US
I don't know how anyone would could expect to know the parameters for all the functions (http://php.net/manual/en/indexes.functions.php) in PHP or in any language. I never understood that complaint. Plus, the major libraries are very consistent e.g., array and string functions following the same needle/haystack/options or haystack/needle/options with their paramenters.

I don't understand what major features for encapsulation and polymorphism that PHP lacks. You'd have to explain that to me.

If you implement a class with ArrayAccess and Iterator you can achieve the result you want. I recall that you have to add a first property to support reset(), but you can make it work if that's what you really need. And you only need to implement it once!

I understand that you may not like strlen($str) and prefer $str->strlen() but I just don't know how that can be a major complaint. Scalar objects are mainly for consistency, but I really don't think they are a necessary improvement. Even languages with OO scalars have functions to deal with undefined objects without errors.

Finally, if it is just a hobby site you can certainly find cheap hosting that allows you to use any language that you think it best. What language do you consider the best for how you like to program?

_________________
(#10850)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 4 posts ] 

All times are UTC - 5 hours


Who is online

Users browsing this forum: Bing [Bot], kintatarpus and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group