Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:44855
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.20090708224156.0ac5a438@zend.com>
Date: Thu, 09 Jul 2009 10:47:41 +0300
To: internals@lists.php.net
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Type hinting - Request for Discussion
From: zeev@zend.com (Zeev Suraski)

All,

I think that we should revisit the options on the table.  I have a 
feeling that much like many people didn't realize they're voting to 
bring this into 5.3 - many weren't fully aware of the options on the 
table and their implications (to be clear - I'm sure some were, but I 
think many were not).

The options as I see them:

1.  Do nothing.  I think the vote established that this is not what 
people want.

2.  Move forward with the semantics of the current patch.  This 
approach has substantial drawbacks in my opinion, and is a strong 
misfit with the rest of PHP (again, in my opinion).  See previous 
posts from Stas, Rasmus, myself and maybe others illustrating this 
point.  Lukas's 'Strict and Weak Typing RFC' 
(http://wiki.php.net/rfc/typecheckingstrictandweak) has some good 
insight as to why strict typing is problematic in PHP.

3.  Implement 'weak' typing.  What does that mean?  Conversion rules 
will be very similar to those for internal functions, but slightly 
stricter (like I said, if we were to rewrite the conversion rules for 
internal functions today - we'd probably make them slightly stricter, 
too).  For example, if you denote that an argument is supposed to be 
an integer, then a string that looks like an integer (e.g. "17") 
would be silently converted to an integer, however, a string that 
does not look like an integer (e.g. "foo") will error out.  We need 
to come up with a complete pass/fail table, but that would be the 
theme.  Unlike option #2, this fits the rest of PHP quite well 
(except for minor inconsistencies with internal functions - but these 
are dwarfed in comparison to the inconsistencies of option #2).

Two other issues that we need to revisit:
1.  Agree on when it will be implemented - I think it's pretty clear 
it should not go to 5.3.
2.  Make sure people understand *why* we're implementing it - 
performance is certainly *not* the reason.

Before moving ahead with votes or committing the code, I suggest we 
focus on the pros & cons of options #2 and #3.  Since the 
inconsistencies introduced by option #2 are very substantial (between 
internal and userland functions, and also how values behave in PHP in 
general), I suggest we focus on use cases where option #2 would be 
truly needed and superior to option #3.  In other words - what is the 
added value and is it worth the price?

I think we can take Lukas's RFC and either change it or write 
something based on it for weak typing only.  If people here find it 
useful I'll go ahead and do that.

Zeev