Re: Re: String extension proposal

If you really want all that OO support why not just use Python instead of using a PECL extension that is half assed. Yes PHP class support is poor in performance but accelerators help in this area. On Tue, Jun 10, 2008 at 9:10 AM, Jake Conk <jake.conk@gmail.com> wrote: > If you really want all that OO support why not just use Python instead > of using a PECL extension that is half assed. Yes PHP class support is > poor in performance but accelerators help in this area. > > On Tue, Jun 10, 2008 at 3:05 AM, Mark Frawley <markfrawley@gmail.com> wrote: >> 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 >> >> -- >> PECL development discussion Mailing List (http://pecl.php.net/) >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> >