Re: [PHP-DEV] Type hinting misunderstood
On Sat, Jan 05, 2008 at 07:34:04PM -0800, Mike Lively wrote: input is going to makes it's way into your api at some point. Now of course you can (and should) be filtering this input before it is used, but if imo when dealing with a loosely typed language where the same input could be hinted as an int in one function it eventually reaches, and a string in another. The point being I understand you may be targeting 'internal stuff' but programming (especially web development) is centered around manipulating/reading input to perform actions...just because it's not 'intended' doesn't mean it's going to never happen. Also, I am pretty sure PDO returns results from at least mysql and sqlite as strings regardless of their type in the database...or are results from the database also not something type hints are inteded for? PLEASE READ CAREFULLY You have NOT understood what type hinting is about. You are confusing the TYPE and the VALUE. What type hinting means is: * is the TYPE correct ? If so succeed. * can the VALUE be 100% converted to the desired TYPE (eg '5' to int) ? If so succeed. * fail Type HINTING is not type ENFORCEMENT. PHP type juggling is still allowed, so PDO returning results as strings is quite OK as long as what is defined to be numeric *really* has a VALUE that is a number. OK: the above does not apply with some things like resources since you can't convert them to/from a string in a meaninful way. -- Alain Williams Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Chairman of UKUUG: http://www.ukuug.org/ #include std_disclaimer.h -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting misunderstood
Am Sonntag, den 06.01.2008, 11:28 + schrieb Alain Williams: On Sat, Jan 05, 2008 at 07:34:04PM -0800, Mike Lively wrote: input is going to makes it's way into your api at some point. Now of course you can (and should) be filtering this input before it is used, but if imo when dealing with a loosely typed language where the same input could be hinted as an int in one function it eventually reaches, and a string in another. The point being I understand you may be targeting 'internal stuff' but programming (especially web development) is centered around manipulating/reading input to perform actions...just because it's not 'intended' doesn't mean it's going to never happen. Also, I am pretty sure PDO returns results from at least mysql and sqlite as strings regardless of their type in the database...or are results from the database also not something type hints are inteded for? PLEASE READ CAREFULLY You have NOT understood what type hinting is about. You are confusing the TYPE and the VALUE. What type hinting means is: * is the TYPE correct ? If so succeed. * can the VALUE be 100% converted to the desired TYPE (eg '5' to int) ? If so succeed. * fail Type HINTING is not type ENFORCEMENT. PHP type juggling is still allowed, so PDO returning results as strings is quite OK as long as what is defined to be numeric *really* has a VALUE that is a number. You may consider a virtual type like 'numeric' for it, but numeric strings do NOT always behave like integers, so passing a string, when my typehint says int, may cause lots of confusion - Stefan already said this earlier. A simple example: $ php -r 'var_dump( ~1, ~1 );' string(1) � int(-2) Or: $ php -r 'var_dump( 1 ^ 2, 1 ^ 2 );' string(1) int(3) And those operations are used quite a lot, when you work with bitmasks in your application. -- Kore Nordmann (GPG 0xDDC70BBB) Der Hammelherde muss derjenige Hammel, den der Schaefer besonders gut fuettert und der darum zweimal so dick wird wie die Anderen, als Genie erscheinen. Tolstoi (Krieg und Frieden) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] Type hinting misunderstood
On Sun, Jan 06, 2008 at 12:51:20PM +0100, Kore Nordmann wrote: Am Sonntag, den 06.01.2008, 11:28 + schrieb Alain Williams: PLEASE READ CAREFULLY You have NOT understood what type hinting is about. You are confusing the TYPE and the VALUE. What type hinting means is: * is the TYPE correct ? If so succeed. * can the VALUE be 100% converted to the desired TYPE (eg '5' to int) ? If so succeed. * fail Type HINTING is not type ENFORCEMENT. PHP type juggling is still allowed, so PDO returning results as strings is quite OK as long as what is defined to be numeric *really* has a VALUE that is a number. You may consider a virtual type like 'numeric' for it, but numeric strings do NOT always behave like integers, so passing a string, when my typehint says int, may cause lots of confusion - Stefan already said this earlier. A simple example: $ php -r 'var_dump( ~1, ~1 );' string(1) � int(-2) Or: $ php -r 'var_dump( 1 ^ 2, 1 ^ 2 );' string(1) int(3) Thank you for those examples. This is part of why part of the proposal of type hinting is to type juggle on entry to the function. Thus your code above, presumably within the type hinted function, would operate as the programmer intended. The more that I think about it the more that I understand that type hinting will be a boon to PHP and increase the quality of PHP applications. Remember: it is optional, if you don't like it - don't use it. -- Alain Williams Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Chairman of UKUUG: http://www.ukuug.org/ #include std_disclaimer.h -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting misunderstood
Hello Alain, I think you are also confused about PHP type hinting... The manual clearly states: Type Hinting PHP 5 introduces Type Hinting. Functions are now able to force parameters to be objects (by specifying the name of the class in the function prototype) or arrays (since PHP 5.1). And suddenly you want to change that definition to Functions are now able to force parameters to be types that *could be casted* to objects/arrays. That is not going to happen. Type hints are supposed to force parameter to be of a specific type. Any kind of auto conversion would redefine type hinting and would be just another feature that gives PHP haters a reason to rant about. And if you want that '1' is allowed to be passed as parameter (without an actual int cast) because it COULD BE CASTED to int then you gain ABSOLUTELY nothing from the type hint. Then you don't need to introduce them at all. Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting misunderstood
On Sun, Jan 06, 2008 at 01:02:54PM +0100, Stefan Esser wrote:
Hello Alain,
I think you are also confused about PHP type hinting...
The manual clearly states:
Type Hinting
PHP 5 introduces Type Hinting. Functions are now able to force
parameters to be objects (by specifying the name of the class in the
function prototype) or arrays (since PHP 5.1).
And suddenly you want to change that definition to
Functions are now able to force parameters to be types that *could be
casted* to objects/arrays.
That is not going to happen. Type hints are supposed to force parameter
to be of a specific type. Any kind of auto conversion would redefine
type hinting and would be just another feature that gives PHP haters a
reason to rant about.
And if you want that '1' is allowed to be passed as parameter (without
an actual int cast) because it COULD BE CASTED to int then you gain
ABSOLUTELY nothing from the type hint. Then you don't need to introduce
them at all.
No - you have misunderstood me. The actual cast IS part of the proposal.
My mail showing how the checking works might have not be clear on the cast
part - I was talking about the checking -- which has to happen before a cast.
The point that I was trying to make is that the VALUE is preserved. Within
the function type juggling may still happen, allowing an int to be used
as a string (or whatever).
Why I mean by:
Type HINTING is not type ENFORCEMENT.
is that:
function foo(int $a) {}
foo(1); // OK
foo(1); // OK - the string is juggled to an int when the
function is called
// ENFORCEMENT would have (in some interpretations)
caused this to
// FAIL since the function argument was a string.
I suspect that there is quite a lot of agreement, however since what we are
talking about has not been precisely defined we are arguing over different
understandings of what this is about.
Sam Barrow was trying to put together a precise description. It might be good to
wait until he has posted that before we continue going round in circles.
Stefan Esser
--
Alain Williams
Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information:
http://www.phcomp.co.uk/contact.php
Chairman of UKUUG: http://www.ukuug.org/
#include std_disclaimer.h
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting misunderstood
Am Sonntag, 6. Januar 2008 12:28 schrieb Alain Williams: Hello, You are confusing the TYPE and the VALUE. What type hinting means is: * is the TYPE correct ? If so succeed. * can the VALUE be 100% converted to the desired TYPE (eg '5' to int) ? If so succeed. * fail ?php echo (int) 1, br\n; // = 1 echo (int) 1a, br\n; // = 1 echo (int) 1.2, br\n; // = 1 echo (int) a1, br\n; // = 0 ? Which cases should be allowd for? function foo(int $bar); IMHO only foo(1); and maybe also foo(1.0); But then the type conversion for type hinting is different from the type conversion in all other cases which makes PHP probably harder to learn. IMHO a system that makes sure that a variable must contain only specific values would be more useful. $int_number: int; $float_number: float; $range: int 1..12; // month $email_address: emailaddress; $options: options['foo', 'bar', 'alice', 'bob']; The problem is still should 1a convert and assigned to $int_number? But because value checking is a different context than type hinting this is maybe easier to learn. tschuess [|8:) http://www.sven-drieling.de/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting misunderstood
On Sunday 06 January 2008, Alain Williams wrote: On Sun, Jan 06, 2008 at 01:02:54PM +0100, Stefan Esser wrote: Hello Alain, I think you are also confused about PHP type hinting... The manual clearly states: Type Hinting PHP 5 introduces Type Hinting. Functions are now able to force parameters to be objects (by specifying the name of the class in the function prototype) or arrays (since PHP 5.1). And suddenly you want to change that definition to Functions are now able to force parameters to be types that *could be casted* to objects/arrays. That is not going to happen. Type hints are supposed to force parameter to be of a specific type. Any kind of auto conversion would redefine type hinting and would be just another feature that gives PHP haters a reason to rant about. And if you want that '1' is allowed to be passed as parameter (without an actual int cast) because it COULD BE CASTED to int then you gain ABSOLUTELY nothing from the type hint. Then you don't need to introduce them at all. No - you have misunderstood me. The actual cast IS part of the proposal. My mail showing how the checking works might have not be clear on the cast part - I was talking about the checking -- which has to happen before a cast. The point that I was trying to make is that the VALUE is preserved. Within the function type juggling may still happen, allowing an int to be used as a string (or whatever). This would only be confusing and not anything like the original proposal, or anything that I would support or have any use of. Type hinting should force the type, not cast it to the type specified. This proposal is about forcing types and I'm sure pretty much everyone would expect a type-hinted param to be of a forced type, not converted, like every other language I've ever used. Magnus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting misunderstood
On Sun, 2008-01-06 at 11:28 +, Alain Williams wrote:
On Sat, Jan 05, 2008 at 07:34:04PM -0800, Mike Lively wrote:
input is going to makes it's way into your api at some point. Now of
course you can (and should) be filtering this
input before it is used, but if imo when dealing with a loosely typed
language where the same input could be hinted as an
int in one function it eventually reaches, and a string in another.
The point being I understand you may be targeting 'internal stuff' but
programming (especially web development) is
centered around manipulating/reading input to perform actions...just
because it's not 'intended' doesn't mean it's going
to never happen.
Also, I am pretty sure PDO returns results from at least mysql and sqlite
as strings regardless of their type in the
database...or are results from the database also not something type hints
are inteded for?
PLEASE READ CAREFULLY
You have NOT understood what type hinting is about.
You are confusing the TYPE and the VALUE.
What type hinting means is:
* is the TYPE correct ? If so succeed.
* can the VALUE be 100% converted to the desired TYPE (eg '5' to int) ? If so
succeed.
* fail
Type HINTING is not type ENFORCEMENT. PHP type juggling is still allowed, so
PDO returning results as strings
is quite OK as long as what is defined to be numeric *really* has a VALUE
that is a number.
Actually this patch does do type enforcement. Once we start doing
conversions, we get into a gray area concerning the conversion rules.
As I said, this patch is not intended for stuff like $_GET, $_POST,
database data, etc. It is intended for internal functions to your
application.
function requireFile(string $file, bool $getOutput = false, array $args
= array())
{
$obLevel = ob_get_level() ;
ob_start() ;
$return = require_once($file) ;
if ($getOutput)
{
$return = ob_get_clean() ;
}
else
{
if ($_mod['base']['output']['strict'] and
ob_get_length() 0)
{
::error::go('Output generated
in file ' . $file . '.') ;
}
ob_end_clean() ;
}
if ($obLevel !== ob_get_level())
{
::error::go('Output buffering level mismatch
after inclusion of file
' . $file . '.') ;
}
return $return ;
}
This function will not be called using input data.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting misunderstood
On Sun, 2008-01-06 at 15:59 +0100, Magnus Määttä wrote: On Sunday 06 January 2008, Alain Williams wrote: On Sun, Jan 06, 2008 at 01:02:54PM +0100, Stefan Esser wrote: Hello Alain, I think you are also confused about PHP type hinting... The manual clearly states: Type Hinting PHP 5 introduces Type Hinting. Functions are now able to force parameters to be objects (by specifying the name of the class in the function prototype) or arrays (since PHP 5.1). And suddenly you want to change that definition to Functions are now able to force parameters to be types that *could be casted* to objects/arrays. That is not going to happen. Type hints are supposed to force parameter to be of a specific type. Any kind of auto conversion would redefine type hinting and would be just another feature that gives PHP haters a reason to rant about. And if you want that '1' is allowed to be passed as parameter (without an actual int cast) because it COULD BE CASTED to int then you gain ABSOLUTELY nothing from the type hint. Then you don't need to introduce them at all. No - you have misunderstood me. The actual cast IS part of the proposal. My mail showing how the checking works might have not be clear on the cast part - I was talking about the checking -- which has to happen before a cast. The point that I was trying to make is that the VALUE is preserved. Within the function type juggling may still happen, allowing an int to be used as a string (or whatever). This would only be confusing and not anything like the original proposal, or anything that I would support or have any use of. Type hinting should force the type, not cast it to the type specified. This proposal is about forcing types and I'm sure pretty much everyone would expect a type-hinted param to be of a forced type, not converted, like every other language I've ever used. This was the intention I had when I wrote the patch. Automatic type casting would go against the rules of array/class type hints, and require a completely new patch. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting misunderstood
On Sun, 2008-01-06 at 10:55 -0500, Sam Barrow wrote: function requireFile(string $file, bool $getOutput = false, array $args // ... This function will not be called using input data. So is there some way you are ensuring that users of your code NEVER pass a value that trickled down from a checkbox on a form for $getOutput? (Just an example) Saying that something will not be called using some form of input data (either directly or through several chained calls) is kind of silly imo. I am sure there are better arguments/solutions than just saying don't use it with 'input'. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting misunderstood
On Jan 6, 2008 5:55 PM, Sam Barrow [EMAIL PROTECTED] wrote:
As I said, this patch is not intended for stuff like $_GET, $_POST,
database data, etc. It is intended for internal functions to your
application.
function requireFile(string $file, bool $getOutput = false, array $args
= array())
{
$obLevel = ob_get_level() ;
ob_start() ;
$return = require_once($file) ;
if ($getOutput)
{
$return = ob_get_clean() ;
}
else
{
if ($_mod['base']['output']['strict'] and
ob_get_length() 0)
{
::error::go('Output generated
in file ' . $file . '.') ;
}
ob_end_clean() ;
}
if ($obLevel !== ob_get_level())
{
::error::go('Output buffering level mismatch
after inclusion of file
' . $file . '.') ;
}
return $return ;
}
This function will not be called using input data.
I have been watching type hinting for a while now and one thing I
don't understand: hows my object of class lets say FileName that
implements __toString() is wrong parameter for your requireFile()? Why
should I every time calling a function cast variables manually when it
can be perfectly done by PHP automatically?
Sorry for intrusion and thanks for your time.
Giedrius
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting misunderstood
Why I mean by:
Type HINTING is not type ENFORCEMENT.
is that:
function foo(int $a) {}
foo(1); // OK
foo(1); // OK - the string is juggled to an int when the
function is called
// ENFORCEMENT would have (in some interpretations)
caused this to
// FAIL since the function argument was a string.
I have not been following very closely this conversation so this might have
been answered already:
$b = '5';
function foo( int $a )
{
echo gettype( $a );
}
foo( $b );
echo gettype( $b );
what is type of $b after the function call?
--
Mikko Koppanen
Re: [PHP-DEV] Type hinting misunderstood
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mikko Koppanen wrote:
| I have not been following very closely this conversation so this might
have
| been answered already:
|
|
| $b = '5';
|
| function foo( int $a )
| {
| echo gettype( $a );
| }
|
| foo( $b );
|
| echo gettype( $b );
|
|
| what is type of $b after the function call?
Great example that hinting is not converting!
In Sams latest patch and the version I'm voting for, there's no after
because this (should) throw E_RECOVERABLE_ERROR. If you ignore the
error, it's not changed.
- - Markus
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHgTc11nS0RcInK9ARAqRuAKCk8khrBAl7cjkkopkcNUmFOYVD8ACeO8EW
lDN/nxNSxYYv732PBYKJo+Y=
=QfXc
-END PGP SIGNATURE-
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting misunderstood
On Sun, 2008-01-06 at 09:03 -0800, Mike Lively wrote: On Sun, 2008-01-06 at 10:55 -0500, Sam Barrow wrote: function requireFile(string $file, bool $getOutput = false, array $args // ... This function will not be called using input data. So is there some way you are ensuring that users of your code NEVER pass a value that trickled down from a checkbox on a form for $getOutput? (Just an example) Saying that something will not be called using some form of input data (either directly or through several chained calls) is kind of silly imo. I am sure there are better arguments/solutions than just saying don't use it with 'input'. All I can say is that it would be very bad programming practice to include a file based on input data. However if someone was to do this, the worst that can happen is that they get an error and realize they can't do that. The purpose of this is for functions internal to the application that interact with eachother. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting misunderstood
On Sun, 2008-01-06 at 19:18 +0200, Giedrius D wrote:
On Jan 6, 2008 5:55 PM, Sam Barrow [EMAIL PROTECTED] wrote:
As I said, this patch is not intended for stuff like $_GET, $_POST,
database data, etc. It is intended for internal functions to your
application.
function requireFile(string $file, bool $getOutput = false, array $args
= array())
{
$obLevel = ob_get_level() ;
ob_start() ;
$return = require_once($file) ;
if ($getOutput)
{
$return = ob_get_clean() ;
}
else
{
if ($_mod['base']['output']['strict'] and
ob_get_length() 0)
{
::error::go('Output
generated in file ' . $file . '.') ;
}
ob_end_clean() ;
}
if ($obLevel !== ob_get_level())
{
::error::go('Output buffering level
mismatch after inclusion of file
' . $file . '.') ;
}
return $return ;
}
This function will not be called using input data.
I have been watching type hinting for a while now and one thing I
don't understand: hows my object of class lets say FileName that
implements __toString() is wrong parameter for your requireFile()?
No problem. My patch does not have the functionality to detect the
__toString method, but this could be implemented in the future.
Why should I every time calling a function cast variables manually when it
can be perfectly done by PHP automatically?
Well type hinting should be used in places where casting is not necessary. You
won't have to cast variables unless you specifically make
them of the wrong data type, for example $number = 5, or if using form input.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting misunderstood
On Sun, 2008-01-06 at 20:02 +, Mikko Koppanen wrote:
Why I mean by:
Type HINTING is not type ENFORCEMENT.
is that:
function foo(int $a) {}
foo(1); // OK
foo(1); // OK - the string is juggled to an int when the
function is called
// ENFORCEMENT would have (in some interpretations)
caused this to
// FAIL since the function argument was a string.
I have not been following very closely this conversation so this might have
been answered already:
$b = '5';
function foo( int $a )
{
echo gettype( $a );
}
foo( $b );
echo gettype( $b );
what is type of $b after the function call?
It won't get there. By calling foo with a string '5', an error will be
thrown.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
