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
