Because that is, IMO, a bad precedent to start for PHP internal
functions. Too many functions already produce warnings (fopen) and
return a status that can be checked. The solution right now is @ and
that has so much baggage with it that you can now disable that feature
completely making distri
On 24 May 2010 13:09, Zeev Suraski wrote:
> 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
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
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 a
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, eve
At 03:53 24/05/2010, s...@geleia.net wrote:
On Sun, May 23, 2010 9:33 pm, Etienne Kneuss wrote:
> On Sat, May 22, 2010 at 17:04, Zeev Suraski 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
>
On Sun, May 23, 2010 9:33 pm, Etienne Kneuss wrote:
> On Sat, May 22, 2010 at 17:04, Zeev Suraski 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 'weak' typ
Hello,
On Sat, May 22, 2010 at 17:04, Zeev Suraski 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 patch that w
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 value
On Sat, May 22, 2010 at 6:09 PM, Zeev Suraski 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. Please let
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
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" ca
-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: Gn
On Sat, May 22, 2010 at 06:30:15PM +0200, Josh Davis wrote:
> On 22 May 2010 17:04, Zeev Suraski 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 'weak' typ
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
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 functions
On Sun, May 23, 2010 at 7:52 AM, Larry Garfield 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
other queries somed
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 in
On 23 May 2010 07:52, Larry Garfield 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
> wrote:
>> > > On 22.05.2010, at 18:30, Josh Davis wrote:
>> > >> As you wrote, you worked on
19 matches
Mail list logo
