back to 5.4 alpha

(after clarification on what Zeev meant, there was a bit of a follow up
that I'm posting as reply):

How is it different from having both options? Given enough time isn't
it exactly the same thing? Argument verification should not be a
customizable feature.

Collecting the info (for documentation purposes and reflection) is
something else and I think that's fine - and then the only question
that remains is the syntax (which IIRC includes modifiers for
strict/weak that we should probably clean up).

If I understood the idea behind the patch, you want to pass on the
argument validation function to the engine on startup. That means
that overnight there'll be a version of PHP supporting different
validation functions. Or am I missing something?

Well, PHP wouldn't support it directly. But it would allow a zend
extension like Xdebug to provide a strict validation function while
debugging and development. Very similar to the overloaded zend_error_cb
and var_dump() function. During production you'd obviously not have a
caster/strict type validator.

It seems quite clear that "you lot" don't like a strict type check;
whereas another lot don't like a casting typecast. I'd be much for your
option #3 (no scalar type hint/cast/strict check by default); but still
allow other tools to access the information that's been supplied by the
parser. That doesn't even necessarily have to be an argument
validator/cast/type check of course; but simple introspection tools that
makes marshalling data to other more type-sensitive data sources. I've
been working with MongoDB here for the past week, and that'd be such a
data source.

Derick

At 21:38 11/08/2010, Derick Rethans wrote:

So I'd propose doing the following:

1. Moving parameter typing to a feature branch (by branching current trunk
   and
   then rolling back the typing part in the trunk).
2. Starting 5.4 alpha process after that basing on trunk.

Any objections to this?

A little bit; yes. There is indeed 0 consensus for having the strict
typehints. However, instead of removing it altogether, and instead
answering every mail in this thread :P, I wrote/am writing a patch that
removes the hard type checks. It however keeps the parsed structures and
reflection API for it. In this sense, they're actually real hints. The
patch also adds a mechanism similariy to the zend_error_cb mechanism so
that extensions could override the argument type checking. As my use
case for strict checking is development I'd be happy to just move the
hard checks into an extension. I could even offer a soft check. It also
allows some type inference which might be useful for webservice
introspecition generation. I am sure SOAP might have some benefit of
this, and I know that at least pecl/dbus does. The patch is attached,
but not ready (I haven't remove the hard checks yet because things got
busy at work).

Derick

--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug

--

--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug

Hi Derick,

We had a long discussion on RFC and hear you can see the summary of my
opinion:

I think removing the "strict" type hinting (reverting semantic back to
5.3), but keeping the new syntax and reflection API is a good decision.

However I definitely against of "delegation" of type-hinting logic into
different location. PHP should be a solid language with single semantic.
This delegation (zend_verify_arg_type callback) allows any extension to
change schematic as it want and this may lead us into situation when
some scripts will work properly only with or without Xdebug (or other
extension). It also restricts possibilities to optimize ZE and introduce
performance lose (now each ZEND_RECV opcode have to call this callback).
Anyway performance is not the main problem because the patch may be
optimized to call callback only if it's defined.

I would suggest to go forward with this decision partially (without
callback and without zval** instead of zval*)

I hope in some point we will come to conclusion about type-hinting...

Thanks. Dmitry.

Derick Rethans wrote:

So I'd propose doing the following:

1. Moving parameter typing to a feature branch (by branching current trunk and
   then rolling back the typing part in the trunk).
2. Starting 5.4 alpha process after that basing on trunk.

Any objections to this?
A little bit; yes. There is indeed 0 consensus for having the strict
typehints. However, instead of removing it altogether, and instead
answering every mail in this thread :P, I wrote/am writing a patch that
removes the hard type checks. It however keeps the parsed structures and
reflection API for it. In this sense, they're actually real hints. The
patch also adds a mechanism similariy to the zend_error_cb mechanism so
that extensions could override the argument type checking. As my use
case for strict checking is development I'd be happy to just move the
hard checks into an extension. I could even offer a soft check. It also
allows some type inference which might be useful for webservice
introspecition generation. I am sure SOAP might have some benefit of
this, and I know that at least pecl/dbus does. The patch is attached,
but not ready (I haven't remove the hard checks yet because things got
busy at work).

I've spend some more time on this, and have attached a new patch that:

• Removes the strict type verification, changing it back into typehints
  only.
• Keeps the current syntax so that typehints create structures in the
  function entries.
• Keeps the reflection API for the syntax, so that you can query the
  typehints.
• Changed the API so that the verification function can also modify the
  variables.

I've also written a proof of concept extension at
svn://svn.xdebug.org/svn/php/typed and
http://svn.xdebug.org/cgi-bin/viewvc.cgi/typed/?root=php that implements
both the current strict-type verification, and a form of the "option 1"
from
http://wiki.php.net/rfc/typecheckingstrictandweak#option_1_current_type_juggeling_rules_with_e_strict_on_data_loss
(I've not done the E_STRICT warnings for all, as the RFC didn't specifiy
when data loss was considered to occur).

Here follows an example script:

<?php
function errorHandler( $errno, $string )
{
global $ok;
$ok = $errno;
return true;
}

set_error_handler( 'errorHandler' );

$twelve = 12;
settype( $twelve, 'float' );

$values = array(
true, false,
0, 1, 12, $twelve, 12.23,
'true', 'false',
'0', '1', '12', '12abc', '12.0', '12.34', 'foo',
array(1,2,3), array('345' => 12),
NULL, ''
);
$funcs = array(
'testString', 'testFloat', 'testInt', 'testNumeric', 'testScalar', 'testBool', 'testArray',
);

function testString( string $a ) { }
function testFloat( float $a ) { }
function testInt( int $a ) { }
function testBool( boolean $a ) { }
function testArray( array $a ) { }
function testNumeric( numeric $a ) { }
function testScalar( scalar $a ) { }

echo "string float int numeric scalar bool array\n";
foreach( $values as $value )
{
foreach( $funcs as $func )
{
$ok = true;
$func($value);
echo $ok === true ? "pass " : ( $ok === 0x1000 ? "fail " : "warn " );
}
echo ' ', str_replace( "\n", '', var_export( $value, true ) );
echo "\n";
}
?>

And the output (with the three different validation/verification methods:

No validation/verification:

derick@kossu:/home/httpd/html/test/verify-arg$ php -dextension=typed.so -dtyped.mode=0 option2.php
string float int numeric scalar bool array
pass pass pass pass pass pass fail true
pass pass pass pass pass pass fail false
pass pass pass pass pass pass fail 0
pass pass pass pass pass pass fail 1
pass pass pass pass pass pass fail 12
pass pass pass pass pass pass fail 12
pass pass pass pass pass pass fail 12.23
pass pass pass pass pass pass fail 'true'
pass pass pass pass pass pass fail 'false'
pass pass pass pass pass pass fail '0'
pass pass pass pass pass pass fail '1'
pass pass pass pass pass pass fail '12'
pass pass pass pass pass pass fail '12abc'
pass pass pass pass pass pass fail '12.0'
pass pass pass pass pass pass fail '12.34'
pass pass pass pass pass pass fail 'foo'
pass pass pass pass pass pass pass array ( 0 => 1, 1 => 2, 2 => 3,)
pass pass pass pass pass pass pass array ( 345 => 12,)
pass pass pass pass pass pass fail NULL
pass pass pass pass pass pass fail ''

Script type-checks:

derick@kossu:/home/httpd/html/test/verify-arg$ php -dextension=typed.so -dtyped.mode=1 option2.php
string float int numeric scalar bool array
fail fail fail fail pass pass fail true
fail fail fail fail pass pass fail false
fail fail pass pass pass fail fail 0
fail fail pass pass pass fail fail 1
fail fail pass pass pass fail fail 12
fail pass fail pass pass fail fail 12
fail pass fail pass pass fail fail 12.23
pass fail fail fail pass fail fail 'true'
pass fail fail fail pass fail fail 'false'
pass fail fail pass pass fail fail '0'
pass fail fail pass pass fail fail '1'
pass fail fail pass pass fail fail '12'
pass fail fail fail pass fail fail '12abc'
pass fail fail pass pass fail fail '12.0'
pass fail fail pass pass fail fail '12.34'
pass fail fail fail pass fail fail 'foo'
fail fail fail fail fail fail pass array ( 0 => 1, 1 => 2, 2 => 3,)
fail fail fail fail fail fail pass array ( 345 => 12,)
fail fail fail fail fail fail fail NULL
pass fail fail fail pass fail fail ''

"Option 1" type-casting:

derick@kossu:/home/httpd/html/test/verify-arg$ php -dextension=typed.so -dtyped.mode=2 option2.php
string float int numeric scalar bool array
pass pass pass fail pass pass fail true
pass pass pass fail pass pass fail false
pass pass pass pass pass pass fail 0
pass pass pass pass pass pass fail 1
pass pass pass pass pass pass fail 12
pass pass warn pass pass pass fail 12
pass pass warn pass pass pass fail 12.23
pass fail warn fail pass pass fail 'true'
pass fail warn fail pass pass fail 'false'
pass pass pass pass pass pass fail '0'
pass pass pass pass pass pass fail '1'
pass pass pass pass pass pass fail '12'
pass fail warn fail pass pass fail '12abc'
pass pass pass pass pass pass fail '12.0'
pass pass pass pass pass pass fail '12.34'
pass fail warn fail pass pass fail 'foo'
fail fail fail fail fail fail pass array ( 0 => 1, 1 => 2, 2 => 3,)
fail fail fail fail fail fail pass array ( 345 => 12,)
pass pass pass fail fail pass fail NULL
pass fail warn fail pass pass fail ''

I'd hope to commit this patch in the next week or so, so that we can get
started with 5.4.

regards,
Derick

Hi!

I've spend some more time on this, and have attached a new patch that:

• Removes the strict type verification, changing it back into typehints
  only.
• Keeps the current syntax so that typehints create structures in the
  function entries.
• Keeps the reflection API for the syntax, so that you can query the
  typehints.
• Changed the API so that the verification function can also modify the
  variables.

I've just committed that patch, the implements the 3 first elements from
this list. I've also updated my little extension to behave in the same
way as it did with the previous patch:

I've also written a proof of concept extension at
svn://svn.xdebug.org/svn/php/typed and
http://svn.xdebug.org/cgi-bin/viewvc.cgi/typed/?root=php that implements
both the current strict-type verification, and a form of the "option 1"
from
http://wiki.php.net/rfc/typecheckingstrictandweak#option_1_current_type_juggeling_rules_with_e_strict_on_data_loss
(I've not done the E_STRICT warnings for all, as the RFC didn't specifiy
when data loss was considered to occur).

Here follows an example script:

<?php
function errorHandler( $errno, $string )
{
global $ok;
$ok = $errno;
return true;
}

set_error_handler( 'errorHandler' );

$twelve = 12;
settype( $twelve, 'float' );

$values = array(
true, false,
0, 1, 12, $twelve, 12.23,
'true', 'false',
'0', '1', '12', '12abc', '12.0', '12.34', 'foo',
array(1,2,3), array('345' => 12),
NULL, ''
);
$funcs = array(
'testString', 'testFloat', 'testInt', 'testNumeric', 'testScalar', 'testBool', 'testArray',
);

function testString( string $a ) { }
function testFloat( float $a ) { }
function testInt( int $a ) { }
function testBool( boolean $a ) { }
function testArray( array $a ) { }
function testNumeric( numeric $a ) { }
function testScalar( scalar $a ) { }

echo "string float int numeric scalar bool array\n";
foreach( $values as $value )
{
foreach( $funcs as $func )
{
$ok = true;
$func($value);
echo $ok === true ? "pass " : ( $ok === 0x1000 ? "fail " : "warn " );
}
echo ' ', str_replace( "\n", '', var_export( $value, true ) );
echo "\n";
}
?>

And the output (with the three different validation/verification methods:

No validation/verification:

derick@kossu:/home/httpd/html/test/verify-arg$ php -dextension=typed.so -dtyped.mode=0 option2.php
string float int numeric scalar bool array
pass pass pass pass pass pass fail true
pass pass pass pass pass pass fail false
pass pass pass pass pass pass fail 0
pass pass pass pass pass pass fail 1
pass pass pass pass pass pass fail 12
pass pass pass pass pass pass fail 12
pass pass pass pass pass pass fail 12.23
pass pass pass pass pass pass fail 'true'
pass pass pass pass pass pass fail 'false'
pass pass pass pass pass pass fail '0'
pass pass pass pass pass pass fail '1'
pass pass pass pass pass pass fail '12'
pass pass pass pass pass pass fail '12abc'
pass pass pass pass pass pass fail '12.0'
pass pass pass pass pass pass fail '12.34'
pass pass pass pass pass pass fail 'foo'
pass pass pass pass pass pass pass array ( 0 => 1, 1 => 2, 2 => 3,)
pass pass pass pass pass pass pass array ( 345 => 12,)
pass pass pass pass pass pass fail NULL
pass pass pass pass pass pass fail ''

Script type-checks:

derick@kossu:/home/httpd/html/test/verify-arg$ php -dextension=typed.so -dtyped.mode=1 option2.php
string float int numeric scalar bool array
fail fail fail fail pass pass fail true
fail fail fail fail pass pass fail false
fail fail pass pass pass fail fail 0
fail fail pass pass pass fail fail 1
fail fail pass pass pass fail fail 12
fail pass fail pass pass fail fail 12
fail pass fail pass pass fail fail 12.23
pass fail fail fail pass fail fail 'true'
pass fail fail fail pass fail fail 'false'
pass fail fail pass pass fail fail '0'
pass fail fail pass pass fail fail '1'
pass fail fail pass pass fail fail '12'
pass fail fail fail pass fail fail '12abc'
pass fail fail pass pass fail fail '12.0'
pass fail fail pass pass fail fail '12.34'
pass fail fail fail pass fail fail 'foo'
fail fail fail fail fail fail pass array ( 0 => 1, 1 => 2, 2 => 3,)
fail fail fail fail fail fail pass array ( 345 => 12,)
fail fail fail fail fail fail fail NULL
pass fail fail fail pass fail fail ''

"Option 1" type-casting:

derick@kossu:/home/httpd/html/test/verify-arg$ php -dextension=typed.so -dtyped.mode=2 option2.php
string float int numeric scalar bool array
pass pass pass fail pass pass fail true
pass pass pass fail pass pass fail false
pass pass pass pass pass pass fail 0
pass pass pass pass pass pass fail 1
pass pass pass pass pass pass fail 12
pass pass warn pass pass pass fail 12
pass pass warn pass pass pass fail 12.23
pass fail warn fail pass pass fail 'true'
pass fail warn fail pass pass fail 'false'
pass pass pass pass pass pass fail '0'
pass pass pass pass pass pass fail '1'
pass pass pass pass pass pass fail '12'
pass fail warn fail pass pass fail '12abc'
pass pass pass pass pass pass fail '12.0'
pass pass pass pass pass pass fail '12.34'
pass fail warn fail pass pass fail 'foo'
fail fail fail fail fail fail pass array ( 0 => 1, 1 => 2, 2 => 3,)
fail fail fail fail fail fail pass array ( 345 => 12,)
pass pass pass fail fail pass fail NULL
pass fail warn fail pass pass fail ''

cheers,
Derick

--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug

Ilia Alshanetsky wrote:

+1, I think that's the most sensible solution for now that would allow
us to proceed with 5.4, something we all seem to be in agreement on.

A slight aside here, as I have not be bothering about what HAS been
implemented typing wise ... A large section of the code a work with passes a
range of data to functions and classes. If the function gets an integer it
looks up the record with that id, an array assumes the data is already
loaded, and perhaps a string value defines that a new record of that name is
to be created. So I don't want the parameters passed to be tied to a single
type. Is THAT affected by any of the current typing actions?

both suggested type-hinting strategies are optional.
so, you, as developer, are free to not use type-hinting and accept any
data you like

--
Alexey Zakhlestin
http://www.milkfarmsoft.com/

It'd be alpha, you have enough time.

Is it really the new way to do things in php.net? Totally ignore other
developers, discuss things privately, act like the last of the last
and drop a mail to "officially" announce a new release/big change? And
then we feel forced to act?

I cannot talk for the other, but for me it is a no-go, period.

I'm totally against an alpha at this stage. Not before we have
clarified all we need to get a clean release.

Cheers,

Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org