As someone who is very new to Habari and only uses PHP in my spare time I can agree with those points.
It certainly seems more logical to have $post->content->out and is what I would have expected were I not shown otherwise in the examples. With regard to Multibyte functions, the way it is now is almost like learning PHP again. Without reading this thread I may not even have known about the class. I am happy to admit that while I was aware of the multibyte functions in PHP I didn't really understand their purpose of application as it is rare to see examples that use them and I've never had a problem caused by not using them, which is how a lot of people have learned their PHP. While I am glad to know about it, it would be preferable for the difference to be seamless where possible. Andrew On Sun, Sep 7, 2008 at 4:33 PM, rick c <[EMAIL PROTECTED]> wrote: > > 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 [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/habari-dev -~----------~----~----~----~------~----~------~--~---
