|
Posted by Jerry Stuckle on 06/27/07 19:50
james.gauth@googlemail.com wrote:
> On 27 Jun, 17:15, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>> james.ga...@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!
>
> I've seen them, register_globals etc. Just because people write new
> code using deprecated functions shouldn't mean that people who follow
> proper code maintenance practices should suffer.
>
They aren't suffering. They will need to change the code sooner or
later. The choices are to upgrade and do it now, or keep putting it off
for years until the code has been modified several more times and is
harder to modify.
>> At least in Java you get a compiler warning that the method has been
>> deprecated.
>
> Exactly, you'd get a runtime warning that the method you are using is
> deprecated.
>
>>> 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.
>
> If you didn't have access to the error log your program would crash
> and you wouldn't know the reason for it anyway.
>
True - but at least you know you have a problem and can enable the error
display.
>> And yes, I'd much rather have the program crash when there is a problem.
>
> Then I hope your programs release database locks before they do their
> crashing.
>
Not a problem. It's called project management and quality control.
>
>>>> 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.
>
> No, it's the function's responsibility to ensure data passed to it is
> clean.
>
Sorry, basic difference in philosophy. This is going back to Basic and
other languages.
>> 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.
>
> C and C++ do it by fixed typing, PHP gets around it by multiple if
> statements.
>
True. But you can still pass improper parameters in C/C++. And the
function will not check for it. Again - it's the programmer's
responsibility to ensure his code is right. All the function should
have to do is perform its job when the correct parameters are passed.
>>>> 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.
>
> There's a large amount of automation applied to PHP objects. By your
> argument you shouldn't need to define protected object properties, you
> should build a layer to implement them yourself.
>
I said nothing about protected properties, and they have nothing to do
with the discussion.
>
>>>>> 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.
>
> If you are aware that using a variable from outside a function may
> result in a fatal error, you are obligated to type-check it before
> using it.
>
Nope. Not at all.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Navigation:
[Reply to this message]
|