Re: String extension proposal

From: Date: Tue, 10 Jun 2008 10:05:06 +0000
Subject: Re: String extension proposal
Groups: php.pecl.dev 
Request: Send a blank email to pecl-dev+get-5490@lists.php.net to get a copy of this message
Hi there, I hope I'm posting this to the right place. I was following the thread where Jessie Hernandez proposed a String PECL extension. I can see why this ruffled a few feathers but I think it was unfairly dismissed. Here are a few reasons I believe we need an OO interface (for those who want it) to PHP's string functions. 1. We can remove redundant prefixes and function parameters. e.g. OO: $name->replace($search, $replace); Procedural: $str = str_replace($search, $replace, $str); OO: $str->len() Procedural: $len = str_len($str); echo "$str"; is possible as Jessie pointed out due to __toString (I don't have to constantly assign new variables because the class can keep the transformed string. The OO functions would still return the same values as the procedural ones. 2. People on the userspace side are doing this on their own because it is not in the language. I have written my own userspace String class as have the authors of CakePHP. Not to mention Jessie Hernandez bravely submitting her idea of critique. 3. Many PHP extensions have become more OO with time: mysql -> MySQLi (performs many similar functions to userspace libraries - e.g. ADODB) memcache -> Memcache (one advantage of this being a class was their encapsulation of the server pool and the weighting algorithm for switching servers - with the procedural API people had to write their own). Answers to some criticisms: PHP is not Java / It's not the PHP way - Weak argument, PHP has borrowed alot of core syntax, and language constructs from Java, particularly in PHP5. Noone is suggesting PHP becomes Java but let's not pretend PHP has never looked at Java and said "I want that". Performance - That needs to be assessed. How poorly do classes perform in PHP5? What's the point in having an OO language if the classes are too slow to be used in any core functionality? The syntax is more confusing that procedural: Looking at my examples above, I don't believe this is the case, it is hard to be objective about this as some people just hate classes (most of you seem to). However someone won the argument to allow OO functionality into PHP, and extend it in PHP5. Why did efforts stop there? Why not tidy up the core functions a little? (Yes I do consider removing redundant prefixes and parameters and grouping similar functionality into classes tidying up). I believe PHP needs these enhancements / additions to the API. If it doesn't get them it will discourage new developers who prefer OO programming from learning PHP and force existing programmers to use frameworks such as CakePHP or roll their own OO interfaces as they have been doing for many years. Regards, Mark

« previous php.pecl.dev (#5490) next »