Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:48472
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.185 as permitted sender)
Message-ID: <7.0.1.0.2.20100526210202.0db422f8@zend.com>
Message-Id: <7.0.1.0.2.20100525153646.0e813b70@zend.com>
Date: Wed, 26 May 2010 21:05:55 +0300
To: Thomas Nunninger <thomas@nunninger.info>
Cc: internals@lists.php.net
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [PHP-DEV] Type hinting
From: zeev@zend.com (Zeev Suraski)

At 15:05 25/05/2010, you wrote:
>I don't know if I have a full understanding about zval.type on internal
>C-level. But in my code I always use strict type checking in comparisons and
>in functions like in_array that offer that possibility. That's because I
>learned the hard way how much debugging time it saves if I handle my variable
>types with care. (Things like '11111111111111111' == '11111111111111112'
>evaluating to true on 32 bit don't make it better.)
>
>I'd say: the type-juggling is not the *big plus* of PHP. BTW: if I read
>some "PHP is so enterprise-ready" articles, I never read about the advantages
>of weak types. (I'd even liked it, if there would be an optional(!)
>possibility of variable type declaration. Who cares, could use it - others
>ignore it.)

Thomas,

I think that these statements put you in a small minority amongst 
PHP's millions of users.  PHP's type system is one of its key 
benefits, and while there's debate over what kind of type hinting we 
should implement - I don't think there's any meaningful debate 
regarding PHP's weakly typed nature at large.

I think there's also a fairly wide consensus that the 'those who care 
can use it and those who don't can ignore it' approach doesn't hold 
water.  Adding clutter to the language brings about inherent 
complexity - for both those who use it and those who don't (use it or 
not - you're going to start seeing it in frameworks, books, 
tutorials, applications and code snippets - you can't avoid it).

>In contrast to "normal" PHP behavior where the user doesn't care about
>variable types, with type hinting in methods/functions it is explicit what's
>required. Every non-strict type handling is contra-productive. So if someone
>wants to use my function with hints, he needs to care about his types.

Other than the thinking the user 'should care about types' I've yet 
to see any real reason of why type conversion - the same thing that's 
done across the whole of PHP - would be bad.  As mentioned in our RFC 
- there are several fundamental reasons of why the opposite is true.

When you take into account we're primarily talking about option #3 
now (i.e., meaningless conversions such as "abc" -> int or 
array->scalar will be rejected) - there's really hardly any reason at 
all to go for strict typing.

>My opinion:

Mine:
- When a caller sees that a function expects an 'int', he should be 
thinking about the semantics of the value he passes on, and not about 
its zval.type value.
- Adding two separate systems of type hinting is even worse than 
adding strict typing alone.  You get all the issues of strict typing, 
plus the clutter of two disparate systems.
- The only thing that's even worse is having that controlled through 
an .ini setting.  That's not even negotiable - we decided to avoid 
.ini entries that effect the language behavior many years ago.
- If you take strict typing away, you lose almost nothing but the 
warm fuzzy feeling of strong typing.  Auto-converting type hinting is 
more than sufficient to handle PHP's scalar function arguments.

(no offense taken in your post - we're simply clearly very far apart 
in the way we perceive PHP...)

Zeev