On 23 May 2010 07:52, Larry Garfield la...@garfieldtech.com wrote:
On Saturday 22 May 2010 11:43:50 pm Zeev Suraski wrote:
At 01:01 23/05/2010, Hannes Magnusson wrote:
On Sat, May 22, 2010 at 22:39, Lukas Kahwe Smith m...@pooteeweet.org
wrote:
On 22.05.2010, at 18:30, Josh Davis wrote:
Hi!
There was a comprehensive discussion on this functionality a few months back
on the mailing list and the overall consensus was that the functionality
made sense (as was committed) but was to late in the game to be part of the
5.3 branch. So, now that the trunk has been established it went
On Sun, May 23, 2010 at 7:52 AM, Larry Garfield la...@garfieldtech.com wrote:
Everything that comes back from a database does
so as a string. To wit: [...]
This is not entirely true though. mysqlnd will return native types
through PDO or mysqli if you use prepared statements [1] and hopefully
Hi!
I agree. function foo(array $x) {} foo(123); doesn't cast int(123) to
array(123) so introducing different meaning for scalar types feels
very very wrong.
Casting integers to arrays never happened in PHP. Casting strings to
integers and back always happened. Including in internal
Hi!
The bug 51866 was reclassified as docs bug, but I still think it makes a
lot of sense to allow for lenient date parsing. And it's quite easy to
do IMHO - the parser can easily stop at the end of the data or format it
needed and not treat it as an error. And it would help working with user
On Sat, May 22, 2010 at 06:30:15PM +0200, Josh Davis wrote:
On 22 May 2010 17:04, Zeev Suraski z...@zend.com wrote:
As one of the key people who designed PHP's type system I consider strict
type checks completely alien to and counterintuitive in PHP and am therefore
pushing to implement
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/23/2010 01:08 AM, Ilia Alshanetsky wrote:
any mistmatch results in an error
An error that is recoverable. So not only is the strict typing
optional, but type mismatches can be caught and handled.
-BEGIN PGP SIGNATURE-
Version: GnuPG
On 23.05.2010, at 14:44, Sebastian Bergmann wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/23/2010 01:08 AM, Ilia Alshanetsky wrote:
any mistmatch results in an error
An error that is recoverable. So not only is the strict typing
optional, but type mismatches can be caught
On May 23, 2010, at 8:51 AM, Lukas Kahwe Smith wrote:
On 23.05.2010, at 14:44, Sebastian Bergmann wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/23/2010 01:08 AM, Ilia Alshanetsky wrote:
any mistmatch results in an error
An error that is recoverable. So not only is the
On Sat, May 22, 2010 at 6:09 PM, Zeev Suraski z...@zend.com wrote:
I encourage everyone to take another look at this RFC even if you've read
it before.
Thanks,
Zeev
Hi internals,
Last time Zeev wrote an RFC for type hinting, I was (as a user) all for it.
This time is no different.
At 16:10 23/05/2010, Davey Shafik wrote:
We also already have a precedent for type-caring functions in the
ctype_* functions:
$ php -r 'var_dump(ctype_digit(123), ctype_digit((string) 123));'
bool(false)
bool(true)
There's a very specific reason for this behavior - ctype treats
numeric
Hello,
On Sat, May 22, 2010 at 17:04, Zeev Suraski z...@zend.com wrote:
All,
As I mentioned numerous times scalar type hinting is a very controversial
feature in my mind and requires some substantial discussion before we move
ahead to implement it.
As such, I think we should revert the
On Sun, May 23, 2010 9:33 pm, Etienne Kneuss wrote:
On Sat, May 22, 2010 at 17:04, Zeev Suraski z...@zend.com wrote:
As one of the key people who designed PHP's type system I consider
strict type checks completely alien to and counterintuitive in PHP and
am therefore pushing to implement
On Monday 24 May 2010 12:09:30 am Zeev Suraski wrote:
I have to say that I don't really see the logic in either it should
be identical to PHP's conversion rules or it should be 100.000%
different (strict). Adding strict typing would be the largest
inconsistency in PHP's core syntax, ever.
Hi!
I see three key options going forward:
1. Implement the table along the lines of what it looks like now,
perhaps with minor changes.
2. Implement identical conversion rules to the ones that exist in
PHP; That effectively turns type hinting into scalar casting
operators (not saying that's
Hi!
any mistmatch results in an error
An error that is recoverable. So not only is the strict typing
optional, but type mismatches can be caught and handled.
Unfortunately, PHP doesn't have good means to handle such kind of
errors. Global shut up handler is not a good means, as it
16 matches
Mail list logo
