| james.gauth@googlemail.com 2007-06-27, 8:00 am |
| On 26 Jun, 23:29, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> james.ga...@googlemail.com wrote:
>
> 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.
This is exactly the point, better planning. A half-baked operator
overloading scheme which breaks backward compatibility is not
evolution, it's feature creep.
There are two better options that they could've considered:
a) Implement operator overloading in its entirety and allow the base
object prototype to be overloaded
b) Implement this system but only issue a notice or a warning when a
__toString() method is not found
-[color=darkred]
>
> 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.
The documentation is already marked as a bug here so I guess the
designers agree that it's vague:
http://bugs.php.net/bug.php?id=3D41750
>
>
> As I said above, there are numerous instances of much more severe
> changes which break backward compatibility.
The numerous instances you mentioned all had very long deprecation
periods and a way to turn the old functionality back on again. If we
change our APIs we notify our clients and provide them a sufficient
amount of time to change their code. No notification was made and no
deprecation period was given.
>
> Fine, then create a __tostring() function which returns an Object.
Try doing that with StdClass.
>
>
> 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?
You can't define __toString() methods for PHP built-in objects. You
can't fill an array with a mixed set of variables and pass it to
implode() if it contains a PHP built-in object.
I'm saying that in some dark recess of some dark hole there's bound to
be a library which I have no control over which makes use of an object
in a string context and causes a fatal error in a place where it would
be innocuous to simply convert it to 'Object'. Here we go, here's some
code in WURFL (wurfl.sourceforge.net):
function _toLog($func, $text, $requestedLogLevel=3DLOG_NOTICE){
global $wurfl_conf;
if ( !defined('LOG_LEVEL') || LOG_LEVEL =3D=3D 0 ) {
return;
}
if ( $requestedLogLevel =3D=3D LOG_ERR ) {
$warn_banner =3D 'ERROR: ';
} else if ( $requestedLogLevel =3D=3D LOG_WARNING ) {
$warn_banner =3D 'WARNING: ';
} else {
$warn_banner =3D '';
}
//echo "Opening ".$wurfl_conf['WURFL_LOG_FILE']."<br/>\n";
$uname =3D posix_uname();
$_textToLog =3D date('r')." [".$uname['nodename']."
"=2Eposix_getpid()."]"."[$func] ".$warn_banner . $text;
$_logFP =3D fopen($wurfl_conf['WURFL_LOG_FILE'], "a+");
fputs($_logFP, $_textToLog."\n");
fclose($_logFP);
return;
}
Which is more appropriate: Breaking code like this (leading to
possible database inconsistency, or any other amount of problems from
a mid-execution fatal) or issuing a warning and retaining the old
functionality?
> 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.
An instantiation of a user defined class is a variable of the type
'Object'. It's still a PHP-defined type, just because you populate an
object with data or attach functions to a class doesn't change that.
Explain the huge difference because I really must be missing something
here.
>
>
>
>
>
>
> Your fatal error looks perfectly fine to me. Maybe eventually they will
> fix the other errors which allow invalid casting, also.
Yeah, and maybe eventually they'll drop the whole loosely typed
fa=E7ade, implement namespaces and rename the language Java.
|