Hi Jessie, I'd be more than happy to get some examples of how others would implement a string class. I am doing most of my modeling after the .NET 2.0 framework for my objects. I find it to be a well organized and capable framework, especially the new ASP.NET 2.0 features like the Role Manager. It also saves on my documentation, just go look at msdn2.microsoft.com. :) kidding
I started this just for fun and an introduction to C, but I am planning on putting into PECL when it is stable, which is quite far off for the whole framework. Should be ready in time for PHP6. I was just reading all the Unicode docs tonight preparing to start my conversion to support it. Gets quite messy pretty fast. Any word on whether the core team is going to accept the namespace patch? It will be beneficial to my development as well for obvious reasons. Bob > -----Original Message----- > From: Jessie Hernandez [mailto:[EMAIL PROTECTED] > Sent: Friday, November 04, 2005 9:35 PM > To: internals@lists.php.net > Subject: RE: [PHP-DEV] [PATCH] - Standardize argument parsing of objects > > Hi Bob, > > BTW, several months back I started working on a similar String class (you > can see my post at http://news.php.net/php.pecl.dev/2512). It was meant as > an OOP interface to all of the string-handling functions, and also had > smart buffer management for speed. I started working on this hoping to > have > it be a part of the core, but at the time I was presented with several > objections (most of them were because of the generic name chosen, > "String", > and because no one wanted it in the core, only on PECL). Even then, I was > advised to wait for the Unicode changes to be merged before I continued > (don't know if the Unicode work is done yet). > > I stopped working on this extension shortly thereafter and started working > on the namespace patch (which is really more important anyways). I can > post > what I had done at the time if you want to take a look at it (I think I > left the code at work, so it would have to wait till Monday). > > (IMHO, I still think a core String class would be very useful. There are > many extensions that provide both a procedural and OOP interface. Take for > example SQLite. You can either use the sqlite_* functions or use the > SQLiteDatabase class. I don't see why strings should be any different.) > > > Regards, > > Jessie > > > Bob Silva wrote: > > > Hi Marcus, > > > > I think I understand what you are saying. I've added get and set > handlers > > to my objects and can now achieve this: > > > > $a = new ZInt(5); > > $a += 1; > > echo ($a->Equals(6)) ? 'true':'false'; > > > > =true > > > > as well as: > > > > $a = new ZChar('A'); > > $a++; > > echo ($a->Equals('B')) ? 'true':'false'; > > > > =true > > > > Thanks for helping me understand this. An unexpected side-effect is that > > by declaring my objects ahead of time like a typed language, I can use > > natives in an object context which is what I was looking to achieve. I > > still have a lot of testing to do though. > > > > $a = new ZString('PHP'); > > $a .= ' Object Wrappers'; > > echo $a->ToString(); > > > > =PHP Object Wrappers > > > > My ZString objects are immutable, $a is actually a new ZString object > > after the concatenation. > > > > The parameter API (even in HEAD) is still a stumbling block though since > > it only converts objects for "syuTt" specifiers and not the others ("l", > > "b", "d" and preferably "a" which doesn't look possible without breaking > > BC since it relies on the get_properties handler first and > > convert_object_to_type second). > > > > Of course any good language provides a work around: (casting ahead of > > time) > > > > echo wordwrap(new ZString('PHP is cool'), (int)new ZInt(3)); > > =PHP > > is > > cool > > > > > > I really don't know if this will be useful for anyone else but it sure > is > > fun programming it and I'm learning a lot. People that are looking for a > > strongly typed PHP may find it useful once I complete the rest of the > > object framework. Next up is Collections. Again, I really appreciate you > > taking the time to reply to my questions and point me in the right > > direction. > > > > Bob > > > > > > > > > >> -----Original Message----- > >> From: Marcus Boerger [mailto:[EMAIL PROTECTED] > >> Sent: Friday, November 04, 2005 10:59 AM > >> To: Bob Silva > >> Cc: internals@lists.php.net > >> Subject: Re: [PHP-DEV] [PATCH] - Standardize argument parsing of > objects > >> > >> Hello Bob, > >> > >> Friday, November 4, 2005, 11:19:23 AM, you wrote: > >> > >> > Hi Marcus, > >> > >> > OK, I got my learning cap on, why is it the wrong way to call > >> cast_object? I > >> > just copied it from the example for a string param and it worked so I > >> > am curious why it is wrong. I agree the convert_to_* functions are a > >> > better solution for the reasons you mentioned, again, I just followed > >> > the > >> example > >> > for the string case. > >> > >> > I guess I don't see what this modification has to do with the future > of > >> PHP > >> > though. Why restrict the parameter API to objects that can only > convert > >> to a > >> > string value? I'd say the current behavior is almost worthy of a bug. > >> > >> [...] > >> > >> > In regards to the extension, I have the base objects complete: > ZArray, > >> > ZChar, ZBoolean, ZDouble, ZInt, ZString. They all work > interchangeably > >> (for > >> > the most part) with their PHP native counterparts as long as you > aren't > >> > using them on the left side of an expression. > >> > >> And that is where get/set handlers come into play and why calling cat > >> handler alone is incorrect. Apart from that the 5 api has the parameter > >> should_free which should be non null if read and write zval are the > same > >> so that the handler knows it must call zval_dtor on the readval prior > to > >> assigning the new value. Since this interface is borked it has changed > >> in head. There read and write zval must be different and the caller has > >> to take care about any required free/destruction. That you had a look > >> into the stuff and haven't come accross this is again proof that the > >> old api was not only bork but also used wrong. > >> > >> Best regards, > >> Marcus > >> > >> -- > >> PHP Internals - PHP Runtime Development Mailing List > >> To unsubscribe, visit: http://www.php.net/unsub.php > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
