|
|
Posted by Jerry Stuckle on 06/26/07 22:29
james.gauth@googlemail.com wrote:
> On 22 Jun, 02:15, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>> james.ga...@googlemail.com wrote:
>>> I agree with Gosha Bine, PHP prides itself with maintaining backward
>>> compatibility (so much so that there's an unbelievable amount of cruft
>>> in the language) yet they choose to break backward compatibility with
>>> something like this? Why not allow a way to extend the base object
>>> prototype to reproduce the old behaviour (or a more descriptive
>>> behaviour)? Or why not, if a __toString() method isn't found, print
>>> 'Object' instead of throwing an exception?
>> No, PHP has been lousy at maintaining backward compatibility.
>
> Well, since you're using such a convincing argument here, I'll just go
> ahead and refute your statement shall I? Here's the entire list of
> backward incompatible changes made from a MAJOR revision in PHP (4-5):
> http://uk.php.net/manual/en/migration5.incompatible.php
>
> Almost all PHP4 code works perfectly in PHP5. I have to say, that's
> definitely lousy backward compatibility isn't it?
>
First of all, I didn't say just from PHP4 to PHP5. I said in general.
This is just another incompatibility
Let's see... some of the major changes I recall off the top of my head...
Getting rid of short tags (<?)
Dumping registered global vars
Changing long names ($HTTP_xxx_VARS)
Sure, these can still be used via PHP.INI settings - but not for much
longer. Also, please note I didn't say they SHOULDN'T be changed - but
they were changes which required major code rewrites. And some, like
the globals, still causes problems.
Also, things like new constructor names between PHP 4 and PHP 5 will
eventually cause problems. They work for now - but again, not forever.
And how about changing the mysql interface? The say things are going,
mysql_xx calls will go away in some future release and you'll have to
change all of those calls to mysqli_xx calls.
And there have been a lot more.
I know PHP is in transition - and many of these changes needed to be
made. But they required major rewrites of code. They wouldn't have if
the language had been better planned from the start.
>
>>> Even the manual still states:
>>> Objects are always converted to the string "Object". If you would like
>>> to print out the member variable values of an object for debugging
>>> reasons, read the paragraphs below. If you would like to find out the
>>> class name of which an object is an instance of, use get_class(). As
>>> of PHP 5, __toString() method is used if applicable.
>> Which version are you looking at? I don't see this in my 5.2.21
>> version. But it's not unusual for doc to lag the actual code changes, -
>> in PHP or any other product.
>
> I'm looking at the online version, the version you'd expect to be up-
> to-date. The paragraph is contained here:
> http://uk3.php.net/manual/en/language.types.string.php#language.types.string.casting
>
> PHP 5.2 was introduced on the 2nd of November 2006. I hope you're not
> suggesting that the online manual is suffering from 7 months of lag.
>
Yes, but you took the statement out of context. When it says it will
use the __tostring() method if applicable, it is talking about if that
is an object vs. some other type. It says nothing about whether the
system provides a __tostring() function or not.
>
>> Irregardless, they do say they will use the __tostring() method, if
>> available.
>
> They say 'if applicable'. In addition to being vague, it infers that
> there might be cases where __toString() isn't used. Cases where the
> default 'Object' casting would be used can reasonably be assumed to
> be: IN CASES WHERE __toString() IS NOT DEFINED.
>
Sure, it doesn't use __tostring() if it's not dealing with an object,
i.e. a numeric value or a resource.
And I see no reason to infer that this would cause a cast to the default
Object class.
>
>> Good programmers wouldn't leave something like this to the
>> compiler/interpreter; they'd define it themselves, anyway. Otherwise
>> you're just asking for bugs.
>
> Good programmers might not leave it up to the compiler/interpreter,
> but then again, good programmers could do this before they made it
> fatal. You could always check a variable's type before using it in a
> string context, there's no reasonable gain in usability by forcing it
> on you. As a side note, breaking backward compatibility is just asking
> for bugs too.
>
As I said above, there are numerous instances of much more severe
changes which break backward compatibility.
>
>>> No warning is given that if a __toString() method isn't defined it'll
>>> throw an exception and handily fatal for you (since PHP 5.2). They
>>> even state that a __toString() method is used 'if applicable'. I'm
>>> guessing 'if applicable' in this case actually means 'without question
>>> and will cause a fatal error in your scripts if you don't define it
>>> when casting an object to a string'.
>> Gee, just like any other missing method. Again - EXACTLY which version
>> of the doc are you using?
>
> The crux of this argument is that __toString() shouldn't have to be
> defined, therefore it wouldn't be a missing method. Again, the ONLINE
> version. Would you like me to paste the URL again? I'll do that:
> http://uk3.php.net/manual/en/language.types.string.php#language.types.string.casting
>
I can read. Maybe it shouldn't have been defined in the first place. I
tend to agree it shouldn't have been. But now they are correcting this
problem - like they've corrected other "problems" in the past.
>
>>> You *do* gain something from an implicit conversion to 'Object', you
>>> gain the sure knowledge that string type-casting will work in *all*
>>> cases regardless of variable type. You do not have to check what the
>>> type of a variable is every time you would like to use it in a string
>>> capacity. It's as if PHP is desperately trying to not be a loosely
>>> typed language any more. The half-baked type-hinting feature is a
>>> great example of this.
>> You gain a FALSE COMFORT that a string casting will work in some usable
>> manner.
>
> Converting to the string 'Object' is perfectly usable for me. It's
> certainly not harmful. It'd be a FALSE COMFORT if there was a REAL
> DANGER in converting an object to 'Object' but there isn't. My code
> doesn't suddenly become HIGHLY UNSTABLE if I define __toString()
> methods which return 'Object'.
>
Fine, then create a __tostring() function which returns an Object.
>
>>> You lose far more from having your language behave inconsistently
>>> between releases than you gain from forcing mandatory redundant coding
>>> constructs. No mention is made in the change log with regards to what
>>> is a reasonably intrinsic change to the language (type-casting should
>>> be set in stone, or people should at least be made aware of it if it's
>>> changed).
>> You gain consistency - because now you are defining the __tostring()
>> method in a manner which makes sense to your program (and your class).
>> Not something PHP has to guess at.
>
> You lose consistency - because whereas previously you could use any
> variable type in a string context, you can no longer do that. The old
> behaviour was not guesswork, you supplied an object in a string
> context, it became 'Object'.
>
Sure you can - as long as you define a __tostring() function for the
class. No problem. Are you saying this is too hard for you to do?
>
>> In case you don't get it - I'm all for this change. I think one of
>> their more serious mistakes was to implement to implicit string
>> conversion for user-defined objects in the first place. It just
>> encourages more sloppy programming.
>
> I think one of your more serious mistakes is believing that an $object
> variable is anything other than the internal type 'Object'. There is
> no magical difference between the conversion of an array, a resource
> or an object to a string. They all (or used to) return results
> consistent with each other. Why doesn't PHP fatal on the following
> code?
>
Sure there is. An array or a resource are PHP-defined types. A
user-defined object is not. Huge difference. The PHP compiler can
handle PHP defined types. Effectively you can consider PHP has a
__tostring() function already built in for these types.
> <code>
> $a = new StdClass();
> $b = new StdClass();
>
> $c = $a + $b; // $c is now 2
> </code>
>
> PHP casts an object to an integer because it maintains the 'everything
> can cast to an integer' premise.
>
> Here's some more if you like:
> <code>
> $a = new StdClass();
> $a->foo = 'bar';
>
> var_dump($a);
> var_dump((int)$a);
> var_dump((bool)$a);
> var_dump((float)$a);
> var_dump((array)$a);
> var_dump((object)$a);
> var_dump((string)$a); // WHOOPS! FATAL
> </code>
>
> Now tell me that PHP causing a fatal unless you write __toString()
> handlers improves consistency.
>
Your fatal error looks perfectly fine to me. Maybe eventually they will
fix the other errors which allow invalid casting, also.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Navigation:
[Reply to this message]
|