Re: [PHP-DEV] Scalar-type-hinting - which way is the best to go?
But I just wanted to point out that this is something the author (and I) would never expect to happen ... in_array(123abc, array(3, 7, 123, 28)) === true Well, would you never expect select ( '123abc' in (3,7,123,28) ) to return boolean true in SQL? Because it does. Me, I'm happy with the parity of these two languages that so often must work in tandem. YMMV but I don't see anything kooky. As Adam others have pointed out, the author of that blog post used the original input as-is. Akin to passing a var into a sanitization function (by value), getting a return true, and continuing processing w/the initial var. I'm not saying I haven't done plenty of similarly stupid things, but I don't see them as evidence to be entered against, well, anything except my own incompetence. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar-type-hinting - which way is the best to go?
Hello Simon, in_array(123abc, array(3, 7, 123, 28)) === true This is a pointless example, because the first argument of in_array is of type mixed and not int. So, this may cause many headaches, but it is irrelevant to the discussion about scalar type hints. Lazare INEPOLOGLOU Ingénieur Logiciel 2012/3/19 Simon Schick simonsimc...@googlemail.com 2012/3/18 Adam Jon Richardson adamj...@gmail.com: On Sun, Mar 18, 2012 at 7:12 AM, Simon Schick simonsimc...@googlemail.comwrote: Hi, All Just to add an example why I want a more strictly type-check here as we have in the current type-juggling: http://www.brandonsavage.net/an-xss-vulerability-in-the-making/?utm_source=rssutm_medium=rssutm_campaign=an-xss-vulerability-in-the-making I see the example given as one of poor validation, not a reason for more strict type checking in a dynamic, weakly typed language. One could: - use a regex - setting the third argument (strict comparison) of in_array() to true -OR- looping through the array and checking equivalence with === - ensure the type juggled value (the integer form) was returned and used rather than using the original string I actually like the conversation on scalar type hinting, and I've even offered some ideas for integrating a form of it, too. However, poor input validation is not one of the reasons that I would use to justify its inclusion. The goal of proper input validation should be to account for page requests that include invalid data and provide appropriate feedback within the natural flow of the application. Erring out when calling a more strongly typed function at runtime does not provide this type of application flow. Adam Hi, Adam I totally agree that type-hinting should not cover what the programmer should do for validating the given input ... But I just wanted to point out that this is something the author (and I) would never expect to happen ... in_array(123abc, array(3, 7, 123, 28)) === true But that's another thing :) I just wanted to point out that I don't want to have the string 123abc accepted as an integer :) Anyways ... This thread should be a discussion about the whole concept, not the details. Sorry for getting off-context here. Bye Simon -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar-type-hinting - which way is the best to go?
2012/3/18 John Crenshaw johncrens...@priacta.com: 2. Unenforced type hinting: This almost happened in 5.4, but eventually got pulled. More interestingly, the *community* rejected it because it is useless. See the comments at http://sebastian-bergmann.de/archives/900-Scalar-Type-Hints-in-PHP-5.3.99.html for a good picture of why people hated this idea. Previous discussions on this mailing list also point out that this idea would ultimately be a dead end (a very good catch by...someone...). Hi, John Thanks for clarifying that way. I understand why some people want to have that ... to please really all people ... make a solution that fits for EVERYONE. But that would (on the other hand) cause way more confusion if you're working with different projects (using Sebastian Bergmanns example) ... one implementing this the way we would implement Strict type hinting - because that's what he wants ... and another one is implementing it as Casting weak type hinting ... and so on. I know that the user still has to add some code, but I don't like the fact to have additional type-hinting that's just doing nothing - and the user is then adding it if he wants. I'm still for the 3rd solution as it is most likely the current type-hint and is not that strict as the first solution. Just to have it consistent. What I like most here: All parameters that can be converted to the wanted format without loosing something are accepted, all other will stop the execution of the script. Bye Simon -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar-type-hinting - which way is the best to go?
On 3/17/2012 11:46 PM, Marco Pivetta wrote: Thank you for clarifying some things :) 4. Strict weak type hinting: This realm is the most likely to succeed because the core already does something like this for internal functions (via zend_parse_parameters). This balances utility (enforcing the type) with fundamental language design principles (juggling). You need to understand the fundamental language principles to understand why any solution MUST lie somewhere in this realm. Remember that: 1.2 === 12; 2+2 === 4; substr(12345, 2) === 345; This type juggling affects the language in all sorts of ways. For example, PHP uses '.' for concatenation (not '+' like most similar languages) which ensures that there is no ambiguity as to whether you are operating against the integer value or the string value. PHP is designed so that you generally don't have to care whether a value is ACTUALLY an integer or a string internally, it will be treated as whatever type you use it as. In PHP int(2), float(2.0), and string(2) can generally be used completely interchangeably with no variation in results whatsoever. When core devs say that strict typing would make it not PHP anymore, this is what they mean; it would badly violate this core concept. If you want scalar typing, you need a solution that embraces this fundamental design principle. Yeah, I don't want to start a discussion on that now nor start a (probably already repeated) war on it, but I think those principles are dead since very long time... If you think that the essential core functionality of type juggling is dead since very long time you have no business making decisions on the future of PHP. PHP without type juggling is no longer PHP! Call my opinion extreme if you wish, but I believe Rasmus, the owner of the trademark on PHP, has suggested that he would not allow the name PHP to be used if it is removed. If you really, really want strong type in a PHP like language, please fork it, rename it, and go away! See if the market follows you or PHP. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar-type-hinting - which way is the best to go?
2012/3/18 Simon Schick simonsimc...@googlemail.com: 2012/3/18 John Crenshaw johncrens...@priacta.com: 2. Unenforced type hinting: This almost happened in 5.4, but eventually got pulled. More interestingly, the *community* rejected it because it is useless. See the comments at http://sebastian-bergmann.de/archives/900-Scalar-Type-Hints-in-PHP-5.3.99.html for a good picture of why people hated this idea. Previous discussions on this mailing list also point out that this idea would ultimately be a dead end (a very good catch by...someone...). Hi, John Thanks for clarifying that way. I understand why some people want to have that ... to please really all people ... make a solution that fits for EVERYONE. But that would (on the other hand) cause way more confusion if you're working with different projects (using Sebastian Bergmanns example) ... one implementing this the way we would implement Strict type hinting - because that's what he wants ... and another one is implementing it as Casting weak type hinting ... and so on. I know that the user still has to add some code, but I don't like the fact to have additional type-hinting that's just doing nothing - and the user is then adding it if he wants. I'm still for the 3rd solution as it is most likely the current type-hint and is not that strict as the first solution. Just to have it consistent. What I like most here: All parameters that can be converted to the wanted format without loosing something are accepted, all other will stop the execution of the script. Bye Simon Hi, All Just to add an example why I want a more strictly type-check here as we have in the current type-juggling: http://www.brandonsavage.net/an-xss-vulerability-in-the-making/?utm_source=rssutm_medium=rssutm_campaign=an-xss-vulerability-in-the-making Bye Simon -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar-type-hinting - which way is the best to go?
On Sun, Mar 18, 2012 at 7:12 AM, Simon Schick simonsimc...@googlemail.comwrote: Hi, All Just to add an example why I want a more strictly type-check here as we have in the current type-juggling: http://www.brandonsavage.net/an-xss-vulerability-in-the-making/?utm_source=rssutm_medium=rssutm_campaign=an-xss-vulerability-in-the-making I see the example given as one of poor validation, not a reason for more strict type checking in a dynamic, weakly typed language. One could: - use a regex - setting the third argument (strict comparison) of in_array() to true -OR- looping through the array and checking equivalence with === - ensure the type juggled value (the integer form) was returned and used rather than using the original string I actually like the conversation on scalar type hinting, and I've even offered some ideas for integrating a form of it, too. However, poor input validation is not one of the reasons that I would use to justify its inclusion. The goal of proper input validation should be to account for page requests that include invalid data and provide appropriate feedback within the natural flow of the application. Erring out when calling a more strongly typed function at runtime does not provide this type of application flow. Adam
Re: [PHP-DEV] Scalar-type-hinting - which way is the best to go?
2012/3/18 Adam Jon Richardson adamj...@gmail.com: On Sun, Mar 18, 2012 at 7:12 AM, Simon Schick simonsimc...@googlemail.comwrote: Hi, All Just to add an example why I want a more strictly type-check here as we have in the current type-juggling: http://www.brandonsavage.net/an-xss-vulerability-in-the-making/?utm_source=rssutm_medium=rssutm_campaign=an-xss-vulerability-in-the-making I see the example given as one of poor validation, not a reason for more strict type checking in a dynamic, weakly typed language. One could: - use a regex - setting the third argument (strict comparison) of in_array() to true -OR- looping through the array and checking equivalence with === - ensure the type juggled value (the integer form) was returned and used rather than using the original string I actually like the conversation on scalar type hinting, and I've even offered some ideas for integrating a form of it, too. However, poor input validation is not one of the reasons that I would use to justify its inclusion. The goal of proper input validation should be to account for page requests that include invalid data and provide appropriate feedback within the natural flow of the application. Erring out when calling a more strongly typed function at runtime does not provide this type of application flow. Adam Hi, Adam I totally agree that type-hinting should not cover what the programmer should do for validating the given input ... But I just wanted to point out that this is something the author (and I) would never expect to happen ... in_array(123abc, array(3, 7, 123, 28)) === true But that's another thing :) I just wanted to point out that I don't want to have the string 123abc accepted as an integer :) Anyways ... This thread should be a discussion about the whole concept, not the details. Sorry for getting off-context here. Bye Simon -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar-type-hinting - which way is the best to go?
On Sun, Mar 18, 2012 at 7:11 PM, Simon Schick simonsimc...@googlemail.comwrote: Hi, Adam I totally agree that type-hinting should not cover what the programmer should do for validating the given input ... But I just wanted to point out that this is something the author (and I) would never expect to happen ... in_array(123abc, array(3, 7, 123, 28)) === true Hi Simon, That's how we differ in terms of perspective. When I see that in_array() accepts a third argument $strict and that $strict defaults to false, in_array(123abc, array(3, 7, 123)) === true is the behavior I expect for that function: http://php.net/manual/en/function.in-array.php That said, perhaps the documentation could be augmented to help clarify the issue. While example 2 on that page illustrates a non-match using the strict check, it does seem like showing the opposite (a surprising match when $strict is false, such as in the example your link pointed to) would also prove beneficial to users, too. Nice commentary. Adam
[PHP-DEV] Scalar-type-hinting - which way is the best to go?
Hi, all Today I read a post around that: http://nikic.github.com/2012/03/06/Scalar-type-hinting-is-harder-than-you-think As some of us are leading to the 3rd and some to the 4th or other ways described in here (I think we can simply exclude the first one ...) Would it be an option (to get this moved forward) to let people vote which way they like most (or which comes closest to their best-solution)? I pretty much like the 3rd way ... the only thing I see that has not been discussed enough is how to handle integers on 64bit and 32bit installations. Bye Simon -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar-type-hinting - which way is the best to go?
tl;dr: strict type hinting and Boxing based type hinting (the second one with some changes). Just read through it, and I was unaware there's still ideas to continue working on type hinting in PHP. That's good news, at least for me :) I'm just lurking around here, but if my thoughts can help, here they are. Here's a short mapping of considerations related to the various implementations exposed on that blog post: 1. Strict type hinting (also aliased by me YES please, yes!): - It enforces the developer to keep his code cleaner - It helps framework devs in reducing the overhead caused by casting within internal classes - Unsure devs can always call `foo((int) $bar);` if they are unsure of what their code produces. The loss of performance will be only because of crap code. - Documentation of return values will become somehow a must - Throwing exceptions, yes please... Unsure what level anyway... I like the E_CATCHABLE_FATAL way. That gives enough flexibility... 2. Unenforced type hinting: - If you have mixed types, then you just don't need type hinting. Lazy devs can still avoid using it. Lazyness shouldn't really be encouraged, so providing some kind of backwards compatibility just makes the feature useless :\ - This is not a feature, it's just better implicit documentation for methods 3. Casting weak type hinting: - This is just case (1) with implicit casting. In my opinion, developers should do the casts themselves with `foo((int) $bar)`. - Implicit casting in method calls would lead to chaos in tracking bugs (for me). Not to mention warnings in N-level hierarchies where values are pushed forward and backward. Let's throw the exception before it becomes chaos! - I am unsure if it also would degrade performance, but I know very little of internals. 4. Strict weak type hinting: I don't really see allowing any of [int, string, float] for any type hint for int, string or float as a feature. That's a silent failure to my eyes. An alternative could be throwing warnings if there's a type mismatch, otherwise the feature doesn't (again) provide anything new to me... It probably just makes it messier. 5. Boxing based type hinting: This is unrealted to the other 4 points to me. What PHP could probably do for us is to cast an object to a scalar when the object implements the compatible magic method (like `__toString`). Anyway, `__toScalar()` and `__fromScalar($scalar)` feels weak. I'd prefer a strict, well defined list of possible magic methods for the various internal types. Would that be a big performance issue? Marco Pivetta http://twitter.com/Ocramius http://marco-pivetta.com On 17 March 2012 14:38, Simon Schick simonsimc...@googlemail.com wrote: Hi, all Today I read a post around that: http://nikic.github.com/2012/03/06/Scalar-type-hinting-is-harder-than-you-think As some of us are leading to the 3rd and some to the 4th or other ways described in here (I think we can simply exclude the first one ...) Would it be an option (to get this moved forward) to let people vote which way they like most (or which comes closest to their best-solution)? I pretty much like the 3rd way ... the only thing I see that has not been discussed enough is how to handle integers on 64bit and 32bit installations. Bye Simon -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar-type-hinting - which way is the best to go?
On Sat, Mar 17, 2012 at 10:37 AM, Marco Pivetta ocram...@gmail.com wrote: Unenforced type hinting: - If you have mixed types, then you just don't need type hinting. Lazy devs can still avoid using it. Lazyness shouldn't really be encouraged, so providing some kind of backwards compatibility just makes the feature useless :\ - This is not a feature, it's just better implicit documentation for methods I just want to quick point out that I suggested the idea of introducing a scalar type hint that would accept all scalars but would disallow passing in arrays or objects. Additionally, the proposal outlined the option of introducing aliases for the scalar hint (bool, int, float, string) which would help developers better declare their intentions in terms of how they expected to use the scalar type. I don't think Nikita was referring to my idea when he referenced unenforced type hinting, as his examples show that passing in an object or array would both succeed even with an int (scalar) type hint. That said, I couldn't find a proposal suggesting a type hinting proposal that was purely documentational, so I wanted to take the time to make sure there was no miscommunication. Adam
RE: [PHP-DEV] Scalar-type-hinting - which way is the best to go?
From: Marco Pivetta [mailto:ocram...@gmail.com] tl;dr: strict type hinting and Boxing based type hinting (the second one with some changes). Just read through it, and I was unaware there's still ideas to continue working on type hinting in PHP. There's been some recent discussion facilitated by understanding past fears and embracing some foundation principles as requirements of a successful solution (which solves a major problem with the scalar typing discussions from the past.) That's good news, at least for me :) I'm just lurking around here, but if my thoughts can help, here they are. Here's a short mapping of considerations related to the various implementations exposed on that blog post: 1. Strict type hinting (also aliased by me YES please, yes!): If you want scalar typing you'll have to move past this. I go into this a little below, but you should also look through the arguments in the archives. This is too strict (more strict that C++ actually). There are some rock solid arguments that have basically shut the door on this one forever. It will never pass a vote. 2. Unenforced type hinting: This almost happened in 5.4, but eventually got pulled. More interestingly, the *community* rejected it because it is useless. See the comments at http://sebastian-bergmann.de/archives/900-Scalar-Type-Hints-in-PHP-5.3.99.html for a good picture of why people hated this idea. Previous discussions on this mailing list also point out that this idea would ultimately be a dead end (a very good catch by...someone...). 3. Casting weak type hinting: Silently casting and discarding lost data is a huge problem and ultimately doesn't offer any substantial benefit. This was discussed previously. Also creates a dead end. 4. Strict weak type hinting: This realm is the most likely to succeed because the core already does something like this for internal functions (via zend_parse_parameters). This balances utility (enforcing the type) with fundamental language design principles (juggling). You need to understand the fundamental language principles to understand why any solution MUST lie somewhere in this realm. Remember that: 1.2 === 12; 2+2 === 4; substr(12345, 2) === 345; This type juggling affects the language in all sorts of ways. For example, PHP uses '.' for concatenation (not '+' like most similar languages) which ensures that there is no ambiguity as to whether you are operating against the integer value or the string value. PHP is designed so that you generally don't have to care whether a value is ACTUALLY an integer or a string internally, it will be treated as whatever type you use it as. In PHP int(2), float(2.0), and string(2) can generally be used completely interchangeably with no variation in results whatsoever. When core devs say that strict typing would make it not PHP anymore, this is what they mean; it would badly violate this core concept. If you want scalar typing, you need a solution that embraces this fundamental design principle. 5. Boxing based type hinting: This is a hack that's been proposed before, but you don't need to look very far to see why this ultimately breaks down badly. Even aggressive casting additions to the language would not make this work particularly well. Anyone who's ever tried to create a class wrapper for a scalar in C++ (which probably includes the core devs) is not likely to be down with this idea. John Crenshaw Priacta, Inc.
Re: [PHP-DEV] Scalar-type-hinting - which way is the best to go?
Thank you for clarifying some things :) 4. Strict weak type hinting: This realm is the most likely to succeed because the core already does something like this for internal functions (via zend_parse_parameters). This balances utility (enforcing the type) with fundamental language design principles (juggling). You need to understand the fundamental language principles to understand why any solution MUST lie somewhere in this realm. Remember that: 1.2 === 12; 2+2 === 4; substr(12345, 2) === 345; This type juggling affects the language in all sorts of ways. For example, PHP uses '.' for concatenation (not '+' like most similar languages) which ensures that there is no ambiguity as to whether you are operating against the integer value or the string value. PHP is designed so that you generally don't have to care whether a value is ACTUALLY an integer or a string internally, it will be treated as whatever type you use it as. In PHP int(2), float(2.0), and string(2) can generally be used completely interchangeably with no variation in results whatsoever. When core devs say that strict typing would make it not PHP anymore, this is what they mean; it would badly violate this core concept. If you want scalar typing, you need a solution that embraces this fundamental design principle. Yeah, I don't want to start a discussion on that now nor start a (probably already repeated) war on it, but I think those principles are dead since very long time... 5. Boxing based type hinting: This is a hack that's been proposed before, but you don't need to look very far to see why this ultimately breaks down badly. Even aggressive casting additions to the language would not make this work particularly well. Anyone who's ever tried to create a class wrapper for a scalar in C++ (which probably includes the core devs) is not likely to be down with this idea. That's not about working with scalar wrappers (which, anyway, would be very useful in Doctrine). It is about casting any object to array... `((int) $dbTableGateway)` could implicitly cause an sql `COUNT` query and stuff like that :) Maybe I'm too java-ish, but those look like good improvements to me :)
