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
