Summary of string conversion problem View as Markdown

I'm not really sure on what's the best way to handle the string
conversion problem, as I haven't worked with SimpleXML yet. Andi's
examples on the other hand aren't convincing enough for me so here my
comments:

Andi Gutmans wrote:

a) include $obj; will not error out but convert the object to a string
and then include it.

I'd expect that in most cases this would be an invalid filename which
would result in an error message. Nothing lost there.

b) $obj[2] = 3; (where $obj implements a __toString function) isn't
quite defined anymore. Should this work?

The bracket syntax has been deprecated in PHP4 already. Giving a warning
on a high error reporting level seems do the job for me.

c) $arr[$obj] would suddenly work according the __toString().

I remember this being requested as a feature anyway ;-)

go and the way Java chose too (not that I thnk we necessarily need to go
the same way but there were some smart ppl who thought of these issues
before us).

I don't like Java being used for PHP design decisions really. The syntax
is cumbersome and has a different focus (static type checking). Don't
forget that a lot of design decisions for Java were made in the 80s.

My $.2,

• Chris

Hello Andi,

Monday, December 1, 2003, 6:49:09 PM, you wrote:

Hey,

Let's try and summarize this discussion and try and see what solution we
can come up with.
The change which was made in convert_to_string() is quite problematic. It
touches a very fundamental engine function and changes the behavior of tons
of places. For example:
a) include $obj; will not error out but convert the object to a string and
then include it.
b) $obj[2] = 3; (where $obj implements a __toString function) isn't quite
defined anymore. Should this work?
c) $arr[$obj] would suddenly work according the __toString().
Not to say that all sorts of bugs would probably be introduced because all
places which call convert_to_string() would have to be checked.

The second patch which automatically calls __toString() on parameters isn't
quite as bad but I am really not sure this is what we want. Do we want PHP
scripts to become much less readable and have people save their strings in
objects and pass those around? How will passing such objects by reference
work with extension functions which expect their string parameter to be by
reference?

As you can see there are LOTS of problems this would introduce (and most
likely more than I could think of).
In the past it was agreed that
__toString() would be called explicitly but we would let "print" to be
overloaded.

Right now, I think making people call it explicitly is the best way to go
and the way Java chose too (not that I thnk we necessarily need to go the
same way but there were some smart ppl who thought of these issues before us).

I do think that SimpleXML has to be tailored for because I truly think that
it's the best addition to PHP 5 including the new OOP features.
So the question really boils down to what exactly the SimpleXML extension
requires? Can't it return a string when it's in read mode?

Let's try and find the right balance between ease-of-use for extensions
such as SimpleXML and verbosity and a PHP which is not error-prone and as
consistent as possible.
Marcus, reverting the patch was nothing personal.
You can see I have technical issues with it. I think you have been doing
some great patches and you know it :)

The summary of my productive thoughts on this:

Hmmm, the minimum needed is to allow: whatever((string)$obj) then.

The solution to this would be another object handler, say make_printable() and
move the __toString() Call from the cast_object handler into this new one
AND partly reintroduce my patch and voila all are happy?

Maybe this is a really cool idea because it allows all kinds of 'cool'
objects to be written in C, it allows all kinds of language bindings but
without the HIGH __toString() WTF factor (minimal compareable to C++
autoconversion problems for example).

--
Best regards,
Marcus mailto:helly@php.net