Re: String extension proposal
| From: | Mark Frawley | 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