|
|
Posted by Jerry Stuckle on 06/27/07 16:15
james.gauth@googlemail.com wrote:
> On 27 Jun, 14:32, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>> Creating a long deprecation period doesn't solve the problem - it just
>> delays it. And since new code also uses those deprecated features, the
>> longer the deprecation period the worse the problem gets.
>
> It delays the problem so that appropriate action can be taken without
> breaking backward compatibility, that's the point of deprecation. I
> keep track of the PHP change log, I scan for things that are likely to
> impact my code. If you write new code using deprecated features then
> you're asking for problems and that's not what I'm advocating here.
And as I said - it increases the problem because new code IS still being
written to the deprecated functions. Check out past posts in this newsgroup!
At least in Java you get a compiler warning that the method has been
deprecated.
>
>>> 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=LOG_NOTICE){
>>> global $wurfl_conf;
>>> if ( !defined('LOG_LEVEL') || LOG_LEVEL == 0 ) {
>>> return;
>>> }
>>> if ( $requestedLogLevel == LOG_ERR ) {
>>> $warn_banner = 'ERROR: ';
>>> } else if ( $requestedLogLevel == LOG_WARNING ) {
>>> $warn_banner = 'WARNING: ';
>>> } else {
>>> $warn_banner = '';
>>> }
>>> //echo "Opening ".$wurfl_conf['WURFL_LOG_FILE']."<br/>\n";
>>> $uname = posix_uname();
>>> $_textToLog = date('r')." [".$uname['nodename']."
>>> ".posix_getpid()."]"."[$func] ".$warn_banner . $text;
>>> $_logFP = 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?
>> I would much rather see the error so I could fix the problem properly.
>
> Anyone who checks their error log frequently would be aware of the
> error. You'd rather have your program crash than have your program
> issue a warning.
>
Many people, especially on shared hosts, have no access to their error
logs. I do because I have VPS's. But not everyone does.
And yes, I'd much rather have the program crash when there is a problem.
>> But where is this using a predefined __tostring() function, anyway? I
>> don't see it. So the question is irrelevant.
>
> This is what I was hoping you'd write. The error in this function is
> that it assumes the arguments are clean before being passed to it. The
> code should have checked the types of the arguments before using them
> in a string context. The problem is not apparent until the code bails.
>
It is the programmer's responsibility to make sure the parameters are
clean before being passed to it.
Why should 99.9999% of the calls to a functions have decreased
performance because 0.0001% of the calls aren't correct?
This is how C and C++ do it - which is a major part of their efficiency.
And this is how most of the PHP functions work.
>> No, it is no longer a PHP-defined type. It is a user-defined type. It
>> may be derived from a PHP-defined type, but that does not make it
>> PHP-defined.
>
> Please explain why the PHP compiler can handle PHP-defined types but
> user-defined (in your definition) types need to be treated
> differently.
>
Because the compiler built the PHP types and can define appropriate
default actions for them. It does not create user-defined types, and
cannot make an intelligent decision on how to create an appropriate
action for them.
From your argument, you shouldn't need to build a constructor for your
classes, either. The compiler should know how to initialize your
user-defined variables without any help. And you shouldn't need a
destructor; if there is any action you class needs to undo, the compiler
should understand that and be able to do it for you.
>>> Yeah, and maybe eventually they'll drop the whole loosely typed
>>> façade, implement namespaces and rename the language Java.
>> What an asinine comment.
>
> Asinine maybe, but when you start having to type-check *everything*
> instead of having fixed-types from the outset the advantages of a
> loosely-typed language whittle away.
>
No need to type-check everything. All you need to do is define a
__tostring() function if you want to convert the object to a string.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Navigation:
[Reply to this message]
|