Assuming the performance impact is something that can be lived with, I'm in favor of a String class. I may be prejudiced since most of my prior background has been in C++, where I expect to have a specific class for strings. I would expect that many new users of PHP coming to Habari with a desktop programming background would have the same expectation.
There appear to be several benefits to having such a class. Owen noted two. Filters could be registered against the class, to allow text formatting before output. And the class could transparently wrap multibyte capabilities while keep string function call names the same as are used in standard PHP. While many of the examples shown on the web use standard PHP string manipulation functions such as strlen() and substr(), these give users a misleading view of the world. We don't live in an 8 bit ASCII world, the only type of characters with which the standard string manipulation functions work properly. To properly deal with characters outside the ASCII characters, multibyte aware functions must be used. We've seen the results of not doing so in the many tickets regarding bugs in Habari's string manipulations regarding content, tags, and slugs. PHP6 promises to solve this problem by making all standard string functions multibyte aware, but PHP6 isn't out yet, and even after it is, it will be some time before it becomes standard on hosts, so it behooves us to use multibyte aware functions until then. We could do so by filling our code with iconv and mbstring functions, but if we do, when PHP6 does become the standard we'll want to go back and rewrite everything using the standard functions. The use of a wrapper class for string functions avoids this by putting the burden of deciding which functions to use for string manipulations in the class, while the user of the class only has to learn one the class interface. Using a String class to wrap multibyte functionality would make it easier for new users to learn the interface than using a class such as MultiByte, where you have to remember to preface everything with MultiByte::. Syntactically and philosophically a String class in this regard is more pleasing. It would be a true class, calling methods on an object, as opposed to what I'll term a procedural class for want of a better word, which MultiByte is. MultiByte only looks like object oriented programming while actually following a procedural paradigm. If I understand correctly, something similar could be said in regard to registering filters to use with the String class. It appears more logical to say $post->content->out than $post->content_out. The former tells you you are performing an action on the $post->content, while the latter appears to be outputting something that may be related to $post->content, but it different. Here too, I believe the change would make it easier for new users to understand and use the code. Rick On Sep 6, 3:37 pm, "Matt Read" <[EMAIL PROTECTED]> wrote: > On Sat, Sep 6, 2008 at 11:47 AM, Owen Winkler <[EMAIL PROTECTED]> wrote: > > How does this idea sound? (That last implementation might be tricky.) > > I like this idea, if it is used only where needed. Strings that do not > require manipulation should not be doing this. eg. there is no need to > create an object for the string ' by '. > > ... [reverse snip] ... > > > You may be familiar with Habari's syntax of $post->content_out for > > filtering the content of a post upon output. Using the String class > > would let us make this look a bit more logical: > > > echo $post->content->out; // for a whole post, autop filtered on out > > Seems like a lot of overhead, creating new string objects for every > field, just to apply filters. But it does look more logical. :) > > -- > Matt Readhttp://mattread.com --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to habari-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/habari-dev -~----------~----~----~----~------~----~------~--~---
