Re: String Extension Proposal

I searched through the archives and found the following post: http://www.zend.com/lists/php-dev/200410/msg00344.html. It seems that the one who originally mentioned this idea was Wez. Here's what he said in his post: "- unicode support for strings. Tricky topic this one. It would be nice to have some kind of engine level support, but I can't think of a nice way to do it that won't break existing scripts. Instead, it would be nice if we had some kind of "String" class (would be nice to use that as the class name...) that used the overloading features of the engine to make it smell like a regular string. It would be aware of, at least, the most common charset encodings (and perhaps be able to load in tables for others at runtime) and have methods to concatenate, split, index by character position (not byte position) etc. etc. and handle differences in character encodings transparently. This can be developed as a PECL extension for now, but once it matures it would be very nice to see it in the default distribution. I believe that Derick is working on code for transliteration (that just went into PECL CVS) that could also be folded into this." My class already "smells" like a regular string in many ways, and it already has methods to concatenate, index, etc. (there's still several methods that need to be implemented, though). The only thing I haven't done any work on are the character encodings/Unicode support. After the Unicode changes are applied to PHP 5.1, I'll have an idea on how this can be implemented inside the class. I guess what this really boils down to is if Wez' idea is a good one or not. I personally think it is. Consider the sqlite extension: you can use the sqlite_* functions if you want to use it in a procedural way, or you can use the SQLiteDatabase, etc. classes if you want to access the DBs in an OO-fashion. This extension will provide an OO interface to the current "procedural" way of handling strings, just like the SQLiteDatabase class does to SQLite databases. I like OO, but I am definitely not an OO fanatic. I don't agree that "everything must be a class" (in fact, this is one of the reasons why I hate Java). On the other hand, I don't think everything should be handled in a procedural way. An obvious use of classes is when many operations can be performed on a set of data, and a String class is a perfect example. Currently, no single convention is followed for the string handling functions (some start with str_*, others with str* only, and others don't have a prefix at all, like addslashes, preg_replace, trim, ucfirst, etc.). A String class will group all of these functions into methods, and the convenience of this can be seen in some IDEs like Zend Studio, where when you type "->" on an object, all the methods that can be applied to that object appear. It really doesn't matter to me if this gets into the core or if it only lives in PECL, or whether the name is "String", "StringBuilder", or whatever. The question is whether such a class will be useful or not, having in mind what Wez mentioned. I'm open to any ideas/criticisms. If anything, like Sara mentioned, such a class can be used as part of the Zend extension tutorials to demonstrate how to implement object handlers. -- Jessie Derick Rethans wrote: > On Fri, 1 Jul 2005, Wez Furlong wrote: > >> I think there might be some merit to having some kind of String class >> in the core; IIRC Derick was talking about something like that with >> full unicode support. > > ueh? I've no clue what you're talking about. As a loathe OO quite a bit > I would never come up with a crazy idea like a String class myself. > PHP is not Java, and introducting a String class (or any other wrapper > for a type) into the core of PHP is for me a definite no-no. > > Derick