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 :)
Re: [PHP-DEV] Scalar Type Hinting
On Thu, March 8, 2012 5:13 am, Alain Williams wrote: On Thu, Mar 08, 2012 at 11:06:56AM +0200, Arvids Godjuks wrote: Type hints are meant to filter input from external sources Correction, it should read like this: Type hints are _not_ meant to filter input from external sources +1 What they will do is to catch where input from external sources has NOT been correctly filtered -- but that should be a rare event and indicative of a bug. While everybody here routinely filters all input, you're living in a dream world if you think un-filtered data is a rare event. It's still a bug, but definitely not rare. Or perhaps you meant that should be a rare event if we want all PHP apps to be well-written rather than that should be a rare event in terms of BC -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Hinting
Hi Simon!
2012/3/8 Simon Schick simonsimc...@googlemail.com:
Hi Arvids,
I pretty much like this idea as it's more strict. Let me say something
to the questions you pointed out here.
2012/3/7 Arvids Godjuks arvids.godj...@gmail.com:
I realize that with scalars it's not that straight forward, but
complicating things by adding an auto-cast syntax and so on is just
ridiculous. Hints should stay, well, hints. The only problem we have
is complications of accepting numerical strings or numbers as strings.
And what to do with null.
I'd like to handle it the same way as it's handled with the classes
right now. If null is not the default-value you'll get an error when
you pass null in there.
One thing I'd like opened here: If you define a default-value
different than null, should you be able to pass null as well and the
compiler will use the default-value?
function a(bool $bool) {}
a(10); // Kill your self against the wall - write a(true);
If you define bool - use the damn bool!
I like that. What should we do if this appears? As it's now - just
throw an Catchable fatal error and let the script blow-up? I would
go this far.
I think Catchable fatal error should be fine and users are familiar
with such mechanic because it already exists. Consistency, man,
consistency :)
I consider interchangeable only three cases:
1. Numerical string.
2. Integers and floats as strings.
3. Integer and string 0 1 as bool.
Any other cases should error out.
Until now I thought about the weak variable-types as a order ...
string, float, integer, Boolean.
All Boolean values are compatible be an integer (0 or 1) and all
integer are compatible to a float and so on. Do you think it's good to
have it this way? This would mean that you could also get a Boolean
true as string 1 ... I personally don't like that ... but I don't
know where to draw the strict-line.
Now think about that backwards. Can a 1 be passed as a parameter
that expects Boolean? If yes, I'd keep it consistent in both ways.
Bye
Simon
That's a good tricky question, I like it.
Well, I think the lower should work just fine.
function a(bool $int) {};
a(1);
Because it's conversion to bool is straight forward. What of the
integer values [-∞, -1] and [2, +∞]? Really tricky question. From one
point of view they are a valid boolean true in the expressions. But
the question here is not if it's a valid boolean, but the fact that we
want our function to be passed with valid data and be more strict that
usual on what is passed to the function/method. So I would like to see
valid boolean values for a hinted argument these:
true
false
1
0
1
0
Simple and clear.
2012/3/8 Simon Schick simonsimc...@googlemail.com:
Hi,
Just a small addition to what I wrote about handling null ...
function foo(array $d = array()) { var_dump($d); }
foo(null); // This fails with the message: Argument 1 passed to foo()
must be an array, null given
As this code fails I'd not expect to change this behavior for the weak-types.
function foo(int $d = 20) { var_dump($d); }
foo(null); // This should then also fail. Don't care about what's the
default-value.
Bye
Simon
Totally agree here.
I would even say that if you need a null as default value - that
can't be a type hinted argument, because it already has to accept two
different types of data and code inside has to handle that anyway. The
type hint is essentially useless in this situation. Adding something
like function a(null|string $a = null) kind'a silly and again is
adding unneeded complexity.
2012/3/8 Simon Schick simonsimc...@googlemail.com:
2012/3/8 John Crenshaw johncrens...@priacta.com:
Conversion the other way is essential. Consider the following URL:
http://example.com?foo=1
In your PHP script $_GET['foo'] === '1' (a string).
In fact, nearly every input to PHP is a string. This is why PHP was designed
with some seriously robust type juggling on scalars. Any typing proposal
that wants to actually pass a vote is going to have to allow appropriate
implicit conversions from string to other types.
John Crenshaw
Priacta, Inc.
Hi, John
Ok .. the example with the get-parameter is quite good.
You'll often have the case that you submit a string 0 or 1 and
want to have it as boolean (f.e. if you have a dropdown with two
options).
Please keep in mind not to mix it up with checkboxes as unchecked
checkboxes won't be sent back to your webserver :)
Bye
Simon
This is exactly the example for witch type hinting should not be used.
$_GET and $_POST data can be anything - string, number, array (lord,
how many scripts break into fatal errors when you just pass an array
instead of simple string). And passing data from these sources as
params to type hinted functions is a suicide. Type hints are meant to
filter input from external sources - that data should be passed
through filtering and validating layer - only after this you can work
with the data and passing it to type
Re: [PHP-DEV] Scalar Type Hinting
Type hints are meant to filter input from external sources Correction, it should read like this: Type hints are _not_ meant to filter input from external sources -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Hinting
On Thu, Mar 8, 2012 at 10:03 AM, Arvids Godjuks arvids.godj...@gmail.comwrote:
Hi Simon!
2012/3/8 Simon Schick simonsimc...@googlemail.com:
Hi Arvids,
I pretty much like this idea as it's more strict. Let me say something
to the questions you pointed out here.
2012/3/7 Arvids Godjuks arvids.godj...@gmail.com:
I realize that with scalars it's not that straight forward, but
complicating things by adding an auto-cast syntax and so on is just
ridiculous. Hints should stay, well, hints. The only problem we have
is complications of accepting numerical strings or numbers as strings.
And what to do with null.
I'd like to handle it the same way as it's handled with the classes
right now. If null is not the default-value you'll get an error when
you pass null in there.
One thing I'd like opened here: If you define a default-value
different than null, should you be able to pass null as well and the
compiler will use the default-value?
function a(bool $bool) {}
a(10); // Kill your self against the wall - write a(true);
If you define bool - use the damn bool!
I like that. What should we do if this appears? As it's now - just
throw an Catchable fatal error and let the script blow-up? I would
go this far.
I think Catchable fatal error should be fine and users are familiar
with such mechanic because it already exists. Consistency, man,
consistency :)
I consider interchangeable only three cases:
1. Numerical string.
2. Integers and floats as strings.
3. Integer and string 0 1 as bool.
Any other cases should error out.
Until now I thought about the weak variable-types as a order ...
string, float, integer, Boolean.
All Boolean values are compatible be an integer (0 or 1) and all
integer are compatible to a float and so on. Do you think it's good to
have it this way? This would mean that you could also get a Boolean
true as string 1 ... I personally don't like that ... but I don't
know where to draw the strict-line.
Now think about that backwards. Can a 1 be passed as a parameter
that expects Boolean? If yes, I'd keep it consistent in both ways.
Bye
Simon
That's a good tricky question, I like it.
Well, I think the lower should work just fine.
function a(bool $int) {};
a(1);
AFAIR Gustavo, Anthony and Nikic discussed on IRC, that maybe the best
solution for scalar type hints would be the unification of the scalar type
hints with the current implementation of zend_parse_parameters.
the built in php functions are enforcing the function signature via
parsing the parameters through this call.
so for example the above mentioned substr signature is substr ( string
$string , int $start [, int $length ] )
substr(foobar, 123); // works like a charm
substr(foobar, 1.5); // works, no warning/notice, although we lose
precision here,
substr(foobar, 123 asd); // Notice: A non well formed numeric value
encountered
substr(foo, bar); // Warning: substr() expects parameter 2 to be long,
string given
so if we would implement the scalar typehints in a way to map the signature
types to the zpp call, then that would mean that the scalar hints are
consistent across the built-in functions, the documentation, and the
dynamic nature of the language(as one could argue that the current/future
implementation of zend_parse_parameters is in line with the dynamic
casting/type juggling nature of php.
just my 2cents
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
RE: [PHP-DEV] Scalar Type Hinting
From: Arvids Godjuks [mailto:arvids.godj...@gmail.com]
I like that. What should we do if this appears? As it's now - just
throw an Catchable fatal error and let the script blow-up? I would
go this far.
I think Catchable fatal error should be fine and users are familiar with
such mechanic because it already exists. Consistency, man, consistency :)
Yeah, I was a huge advocate of this too until recently. I've changed my mind
though, ironically enough to ensure better consistency.
PHP since 5.3 gives an E_WARNING if you pass poorly-converting scalar data to
an internal function (For example, substr('foo', 'bar');) This changed my mind
about the level of error to raise here. I think there's still a good argument
for E_CATCHABLE_FATAL if you pass something retarded (like a resource, or
possibly even an array), but I think we should strive as far as possible to be
consistent with the behavior of scalars passed to internal functions. This
would allow us to repaint the entire proposal as bringing to the language level
the same level of scalar typing available internally, using the same syntax as
the docs (which sounds much more reasonable and less politically charged than
Please add scalar typing...again.)
See Ferenc's reply about 30 seconds ago for more details on this...
Type hints are meant to
filter input from external sources
Correction, it should read like this:
Type hints are _not_ meant to filter input from external sources
That's not really the point though. The issues with external sources providing
strings comes into play regardless of whether people validated their inputs.
For example, if (is_numeric($priority) $priority = 0 $priority = 3)
will pass and still leaves you with a string, and that string currently works
just fine everywhere as if it were an integer. What's more, the folks that will
be voting on this have made it clear in the past that failure to account for
type juggling in any such proposal is a deal breaker. For many users these
inputs can and will trickle down through the code and eventually cause
frustrating failures if not handled intelligently. You don't have to love it,
but basically if you want a typing proposal to have any chance I think you'll
have to support it.
John Crenshaw
Priacta, Inc.
Re: [PHP-DEV] Scalar Type Hinting
On Thu, Mar 08, 2012 at 11:06:56AM +0200, Arvids Godjuks wrote: Type hints are meant to filter input from external sources Correction, it should read like this: Type hints are _not_ meant to filter input from external sources +1 What they will do is to catch where input from external sources has NOT been correctly filtered -- but that should be a rare event and indicative of a bug. -- Alain Williams Linux/GNU 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 #include std_disclaimer.h -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Hinting
2012/3/8 John Crenshaw johncrens...@priacta.com:
From: Arvids Godjuks [mailto:arvids.godj...@gmail.com]
I like that. What should we do if this appears? As it's now - just
throw an Catchable fatal error and let the script blow-up? I would
go this far.
I think Catchable fatal error should be fine and users are familiar with
such mechanic because it already exists. Consistency, man, consistency :)
Yeah, I was a huge advocate of this too until recently. I've changed my mind
though, ironically enough to ensure better consistency.
PHP since 5.3 gives an E_WARNING if you pass poorly-converting scalar data to
an internal function (For example, substr('foo', 'bar');) This changed my
mind about the level of error to raise here. I think there's still a good
argument for E_CATCHABLE_FATAL if you pass something retarded (like a
resource, or possibly even an array), but I think we should strive as far as
possible to be consistent with the behavior of scalars passed to internal
functions. This would allow us to repaint the entire proposal as bringing to
the language level the same level of scalar typing available internally,
using the same syntax as the docs (which sounds much more reasonable and less
politically charged than Please add scalar typing...again.)
See Ferenc's reply about 30 seconds ago for more details on this...
Well, it may be that way too, but I have to point out that language
level functions are built in and you can't add or remove a type hint
for them. It expects integer and does it's best to make it an integer,
even if it gives some weird result. And backwards compability is an
issue here - _the_ _main_ _issue_. At the language level you have to
maintain that BC and sure if you make zend_parse_params reject strings
where an in should be without any warning - you sure have a rage storm
on the internet that will crush you to peaces.
Adding optional type hinting isn't bound to that BC, because we have
no scalar type hints at all. In 5.3 they added E_NOTICE and E_WARNING
to zend_parse_params. Are you sure they would not change the E_WARNING
to E_ERROR in say PHP 6? Or bump E_NOTICE to E_WARNING? What if
type-juggling rules change? If that will happen - you will have your
type hint behavior change between versions and I think that's not
really a good idea.
So from one point of view it's a nice idea to tie that to
zend_param_parse, but from the other side that does not look like a
good idea. Internals of the engine tend to change more often than the
external syntax and behavior.
Type hints are meant to
filter input from external sources
Correction, it should read like this:
Type hints are _not_ meant to filter input from external sources
That's not really the point though. The issues with external sources
providing strings comes into play regardless of whether people validated
their inputs. For example, if (is_numeric($priority) $priority = 0
$priority = 3) will pass and still leaves you with a string, and that string
currently works just fine everywhere as if it were an integer. What's more,
the folks that will be voting on this have made it clear in the past that
failure to account for type juggling in any such proposal is a deal breaker.
For many users these inputs can and will trickle down through the code and
eventually cause frustrating failures if not handled intelligently. You don't
have to love it, but basically if you want a typing proposal to have any
chance I think you'll have to support it.
John Crenshaw
Priacta, Inc.
That's why I described the rules when type juggling comes into play.
If you send a string number, it is converted from string to number by
the type hint. If you send a string of characters and pass it to a int
type hinted function - sorry, but it's you who shout yourself with a
shotgun, not someone else.
I have to repeat it again - type hinting is not for converting and
filtering data. It is not meant to be used in code witch deals with
user input.
You will never write a code like this in 5.3 or 5.4
?php
function processArray(array $data) {
foreach ($data as $k = $v) {
// Do something
}
}
processArray($_POST['some_var']);
?
Should I tell you why? I think you know. Same goes for hinting
integer, string, float, bool or any other type. To convert data we
have conversion operators and functions like settype. Hints only
should take into account that a validated param can be a number in
string representation and change the type accordingly. But if passed
something different than a number - fail.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Scalar Type Hinting
From: Arvids Godjuks [mailto:arvids.godj...@gmail.com] That's why I described the rules when type juggling comes into play. If you send a string number, it is converted from string to number by the type hint. If you send a string of characters and pass it to a int type hinted function - sorry, but it's you who shout yourself with a shotgun, not someone else. If you are determined to have it this way and cannot yield, then you are off topic. This thread was built around the explicit premise that any scalar type hint MUST be more forgiving than that, and if we take that away there's quite literally nothing more to talk about. Regardless of how anyone feels about it, the core devs will never accept what you are insisting on above. (If you want proof, look at the prior debates on this issue.) This discussion has no purpose unless it can actually accomplish something meaningful, so it started by accepting this as a fundamental requirement. Allowing strings to be implicitly converted to lower types when possible, regardless of whether the reason offends your sense of how code should have been written, is a vital compromise in the process of improving the typing in PHP. John Crenshaw Priacta, Inc.
Re: [PHP-DEV] Scalar Type Hinting
AFAIR Gustavo, Anthony and Nikic discussed on IRC, that maybe the best
solution for scalar type hints would be the unification of the scalar type
hints with the current implementation of zend_parse_parameters.
Yeah, that's basically what we were discussing. However, there's one
significant issue that I personally have to doing that. in ZPP, if
you have a parameter that expects an array, and pass it an int, a
warning is raised. But then the main body of the function is skipped
(the function isn't executed) and the control is passed back to the
calling code.
To me, that's not right at all. That basically forces all code to use
boolean return error checking. Even if you wanted to use exceptions,
you'd still need to wrap the calling code in an if() statement to see
if a parameter errored. To me, that makes a *direct* port of zpp a
no-go for userland code. Sure, it would be consistent, but it would
also lead to some very hard-to-read code if you wanted to make it
robust:
try {
if (!foo($bar)) {
return false;
}
} catch (FooException $e) {
// We want to ignore it, because we're maintaining the abstraction
and can fix it
bar();
return false;
}
return true;
All that code, just to make a robust function call. Not good in my book.
the built in php functions are enforcing the function signature via
parsing the parameters through this call.
so for example the above mentioned substr signature is substr ( string
$string , int $start [, int $length ] )
substr(foobar, 123); // works like a charm
substr(foobar, 1.5); // works, no warning/notice, although we lose
precision here,
substr(foobar, 123 asd); // Notice: A non well formed numeric value
encountered
substr(foo, bar); // Warning: substr() expects parameter 2 to be long,
string given
so if we would implement the scalar typehints in a way to map the signature
types to the zpp call, then that would mean that the scalar hints are
consistent across the built-in functions, the documentation, and the
dynamic nature of the language(as one could argue that the current/future
implementation of zend_parse_parameters is in line with the dynamic
casting/type juggling nature of php.
What I do like, is the rules for error or no error. How it determines
if a zval can be passed to a hint of integer. And I also like that it
casts if those rules pass...
However, I think the errors that it throws are far too kind, and can
be quite confusing and lead to difficult to defend code (meaning that
you need 10 or 15 lines of code to defensively call a piece of code).
Instead, I'd much prefer the error level be raised to
E_RECOVERABLE_ERROR, or throw an exception on those typing errors. At
least in user type hints, and preferably in ZPP as well. If the
function is not going to be executed, it should raise a much more
substantial error... Otherwise *that* is going to be more confusing
than anything else IMHO...
just my 2cents
Thanks for the reply!
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Hinting
On Thu, 08 Mar 2012 13:38:32 +0100, Anthony Ferrara ircmax...@gmail.com wrote: AFAIR Gustavo, Anthony and Nikic discussed on IRC, that maybe the best solution for scalar type hints would be the unification of the scalar type hints with the current implementation of zend_parse_parameters. Yeah, that's basically what we were discussing. However, there's one significant issue that I personally have to doing that. in ZPP, if you have a parameter that expects an array, and pass it an int, a warning is raised. But then the main body of the function is skipped (the function isn't executed) and the control is passed back to the calling code. Not really, that's just a convention that if zpp fails functions return null or false immediately (which one is used depends on the extension, current weather, etc.). That's because there's a convention that builtin functions don't raise exceptions. But nothings stops them from falling back or suppressing the warning/notice (and some do, esp. if they support distinct sets of arguments). Some extensions (and constructors even in extensions that use false for error) actually force an exception if zpp fails (usually via zend_replace_error_handling). But of course this is not an option in user code because: 1) you can't change the error handling before parsing the parameters and 2) inside the function you can't tell whether some argument parsing error occurred. So E_RECOVERABLE_ERROR in the cases where zpp would return FAILURE seems in fact the only viable option, even with the disadvantages it has (centralization and lack of flexibility). Still, the fact that 100% consistency is not possible is not a strong argument against at least *some* consistency and in favor of inventing new rules. [...] -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Hinting
2012/3/8 John Crenshaw johncrens...@priacta.com:
From: Arvids Godjuks [mailto:arvids.godj...@gmail.com]
That's why I described the rules when type juggling comes into play.
If you send a string number, it is converted from string to number by the
type hint. If you send a string of characters and pass it to a int type
hinted function - sorry, but it's you who shout yourself with a shotgun, not
someone else.
If you are determined to have it this way and cannot yield, then you are off
topic. This thread was built around the explicit premise that any scalar type
hint MUST be more forgiving than that, and if we take that away there's quite
literally nothing more to talk about. Regardless of how anyone feels about
it, the core devs will never accept what you are insisting on above. (If you
want proof, look at the prior debates on this issue.) This discussion has no
purpose unless it can actually accomplish something meaningful, so it started
by accepting this as a fundamental requirement. Allowing strings to be
implicitly converted to lower types when possible, regardless of whether the
reason offends your sense of how code should have been written, is a vital
compromise in the process of improving the typing in PHP.
John Crenshaw
Priacta, Inc.
Well, if your type hints gets more forgiving, than it's the same that
was proposed by this
function a((int) $arg) {}
And in this case hints have no meaning at all - it's just other syntax
to do the conversion that now looks like this
function a($arg) { $arg = (int)$arg; }
And please give an answer to this question: If we make hints forgiving
(like type casting), then what we have to do with current array type
hints - it gives error on anything but arrays? Change it back so it
does a conversion to array? Sorry, but it will make a mess in my code,
because I already use hints for arrays and objects and changing their
behavior is just out of the question.
I do not remember devs explicitly saying that something like I
proposed will not be accepted. They said there will be no strict type
hinting or strict variable typing. And they do not want to add another
syntax for type juggling functionality. So, if only i'm not mistaken,
my idea is somewhere in between and doesn't look weird or
extraordinary. It just adds ability to make arguments of the
function/method be more picky about what they can receive.
Maybe i'm mistaken, but I have a distinct impression that many of the
posters will use type hints all over the place if and when they will
be added and base their ideas on that. Don't get me wrong, but the
auto-casting type hints are really needed only when you really write
all the code with type hints in every function/method you define and
you don't want to do manual conversions all the time.
Maybe this is that case when people tend to get min-max and do not
consider the average use? My average use of currently available type
hints is low in WEB environment and only in internal stuff where user
input doesn't make in unchecked. And I had quite a good use of them in
a console daemon where there is no user input at all (only working
with database).
As to breaking some BC when making keywords such as string, int,
float - that's what the major releases are for. When you introduce
ANY keyword there is a possibility that someone is using it and it
will break his application. It's a risk, yes. But now days refactoring
instruments are very good and changing class name thought out the
project is no big deal really - just make sure people are informed.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Hinting
Gustavo, Not really, that's just a convention that if zpp fails functions return null or false immediately (which one is used depends on the extension, current weather, etc.). That's because there's a convention that builtin functions don't raise exceptions. But nothings stops them from falling back or suppressing the warning/notice (and some do, esp. if they support distinct sets of arguments). Some extensions (and constructors even in extensions that use false for error) actually force an exception if zpp fails (usually via zend_replace_error_handling). Quite fair... But of course this is not an option in user code because: 1) you can't change the error handling before parsing the parameters and 2) inside the function you can't tell whether some argument parsing error occurred. Which is the point. So E_RECOVERABLE_ERROR in the cases where zpp would return FAILURE seems in fact the only viable option, even with the disadvantages it has (centralization and lack of flexibility). So, at that point, then it sounds like we have a spec. Functionality of zpp, with an E_RECOVERABLE_ERROR where zpp would fail. Including any warnings or notices that zpp would have raised anyway (since `1abc would work when passed to an int, it should still work, notice intact). Still, the fact that 100% consistency is not possible is not a strong argument against at least *some* consistency and in favor of inventing new rules. Sure. Makes sense. I'll work on a proof-of-concept this weekend. That is if nobody else wants to take it (or beats me to it) :-D. Thanks, Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Scalar Type Hinting
Well, if your type hints gets more forgiving, than it's the same that was
proposed by this function a((int) $arg) {} And in this case hints have no
meaning at all - it's just other syntax to do the conversion that now looks
like this function a($arg) { $arg = (int)$arg; }
That's black and white thinking. Casting is obviously too forgiving (a cast
literally accepts ANYTHING), and there were specific problems identified with
that syntax that have absolutely nothing to do with whether you can juggle
parameter types.
Current sentiment seems to be settling around behavior similar to the internal
zend_parse_parameters, which is to say:
(function(int){})('1'); // no error
(function(int){})('123xyz'); // E_NOTICE, function gets (int)1
(function(int){})('xyz'); // E_WARNING, function gets (int)0
Someone (you?) made a good case for questioning these warning levels, but the
basic concept of what to accept and what to warn about is good, and already in
use (which makes it far easier to accept).
And please give an answer to this question: If we make hints forgiving (like
type casting), then what we have to do with current array type hints - it
gives error on anything but arrays? Change it back so it does a conversion
to array? Sorry, but it will make a mess in my code, because I already use
hints for arrays and objects and changing their behavior is just out of the
question.
Array behaves as it always has (E_RECOVERABLE_ERROR if you don't pass an
array). Scalar types don't implicitly convert (juggle) to arrays, so there's
no issue there. There's no reason to attempt to support any implicit conversion
from array to string either. E_RECOVERABLE_ERROR would be perfectly appropriate
here (or you could argue to raise E_WARNING, which is technically what
zend_parse_parameters does).
I do not remember devs explicitly saying that something like I proposed will
not be accepted. They said there will be no strict type hinting or strict
variable typing. And they do not want to add another syntax for type juggling
functionality. So, if only i'm not mistaken, my idea is somewhere in between
and doesn't look weird or extraordinary. It just adds ability to make
arguments
of the function/method be more picky about what they can receive.
Look back at the discussion and arguments. The string input thing comes up over
and over again. Resisting this point simply caused frustration and ultimately
turned into a consistent battle cry of we're never going to add strict typing
because it breaks the language and virally affects all the code up the chain.
The input parameters became a poster child case, but conceptually if you make
this too strict it virally forces everything up the stack to behave strictly as
well (hence the frequent arguments, it will break the language, and it would
no longer be PHP.)
You can disagree, that's totally fine, but *this* discussion assumes that a
successful proposal must take the opposite route, and fully embrace string
inputs and limited type juggling.
Maybe i'm mistaken, but I have a distinct impression that many of the posters
will use type hints all over the place if and when they will be added and base
their ideas on that. Don't get me wrong, but the auto-casting type hints are
really needed only when you really write all the code with type hints in every
function/method you define and you don't want to do manual conversions all the
time.
I'd use it liberally, especially in models, but not universally by a long shot.
Type hints aren't designed to make life easier for the caller (though they
should avoid making it harder). Type hints are connected to the algorithm of
the function itself; they offer a logical guarantee to the function that the
types of the parameters are consistent with the nature of the algorithm. For
example, an add() function needs to be able to trust that parameters will be
numeric, substr needs to be able to trust that parameters will be a string + an
integral value, and so on.
If the logic requires this simple assurance, I'll use a hint. If not, I won't.
Maybe this is that case when people tend to get min-max and do not consider
the
average use? My average use of currently available type hints is low in WEB
environment and only in internal stuff where user input doesn't make in
unchecked.
And I had quite a good use of them in a console daemon where there is no user
input at all (only working with database).
The current hints consist only of arrays and classes. These *can't* be user
inputs (well, arrays can, but really, that's so rare for someone to actually
use.) Checked or unchecked is basically irrelevant, because these parameters
could never have originated as user data anyway. Strings, integers, numbers,
values used in boolean checks, these all can and will originate as user data,
which is the concern raised over and over in the past. This is a fair argument.
One can argue that people shouldn't have
Re: [PHP-DEV] Scalar Type Hinting
On Thu, Mar 8, 2012 at 6:08 PM, John Crenshaw johncrens...@priacta.comwrote:
Well, if your type hints gets more forgiving, than it's the same that was
proposed by this function a((int) $arg) {} And in this case hints have no
meaning at all - it's just other syntax to do the conversion that now
looks
like this function a($arg) { $arg = (int)$arg; }
That's black and white thinking. Casting is obviously too forgiving (a
cast literally accepts ANYTHING), and there were specific problems
identified with that syntax that have absolutely nothing to do with whether
you can juggle parameter types.
Current sentiment seems to be settling around behavior similar to the
internal zend_parse_parameters, which is to say:
(function(int){})('1'); // no error
(function(int){})('123xyz'); // E_NOTICE, function gets (int)1
(function(int){})('xyz'); // E_WARNING, function gets (int)0
I don't think it's fair to say that casting is too forgiving OR that
current sentiment is settling around behavior similar to the internal
zend_parse_parameters. This is a complex issue, and there are many core
developers who have been focusing on other things besides this discussion.
Their silence likely does not demonstrate sentiment of approval for
anything at this point. This particular subject has much history on the PHP
mailing list, and the opinions are far ranging. More importantly, this
general subject has much history in all of the programming languages that
are dynamically typed.
One can find similar discussions regarding Ruby, Python, and general
discussions of type:
http://www.codecommit.com/blog/ruby/adding-type-checking-to-ruby
http://stackoverflow.com/questions/734368/type-checking-of-arguments-python
http://journal.stuffwithstuff.com/2010/08/31/type-checking-a-dynamic-language/
And, while there are some dynamically typed languages that allow optional
types, they don't provide much help here, either:
- Clojure allows type hints, but they're just for performance reasons.
http://clojure.org/java_interop
- Dart has optional types, but in Dart, everything is an object AND it's
types are unsound (i.e., let you get away with lots):
http://www.dartlang.org/articles/why-dart-types/
My point is that there are many beliefs about how to handle optional type
checks on function arguments in dynamic, weakly typed languages, and
there's not much precedent. That's not to say that nothing should be added
to PHP's capabilities. However, one constant question that emerges when
considering types in dynamic languages is what does it really buy you? The
value has to be significant, especially considering the lack of a compiler
that can ensure the correctness of a type before runtime. As Stas pointed
out in the thread for the Enun RFC (noting the importance of a compiler):
One note here: Java is a statically typed compiled language. PHP is not. So
many arguments regarding type safety, etc. which are completely valid in
regards to Java have no validity in regard to PHP. I understand that some
people want to import some bits from strictly typed languages, imagining
that this will provide them with benefits that statically typed languages
have, namely compile-time safety checks, etc. This does not work as well in
dynamic languages. Note for example that neither Ruby nor Python have
enums, though you can do similar things there.
Let's look at the examples you gave:
(function(int){})('1'); // no error
(function(int){})('123xyz'); // E_NOTICE, function gets (int)1
(function(int){})('xyz'); // E_WARNING, function gets (int)0
I'm wondering where you would be getting the values '123xyz' and 'xyz' from
at runtime that you're passing off to a function expecting ints? If these
come from GPC's, then wouldn't an app pick up the issue BEFORE getting to
the point that they're being used as arguments through proper input
validation. And, if these come from a MySQL database, then wouldn't they
have been stored in a field that only stores some type of int (otherwise
one wouldn't be passing them to a function expecting ints.) And, if it
comes from a file, wouldn't the input be validated there, too, before
calling this function? Now, I'm not saying there are no examples, but they
would appear to be very limited in applications.
Joe Armstrong, creator of the dynamically typed Erlang language, advocates
performing checks on the datatypes at the points in the application that
receive input, but not within the internal functions. It's an interesting
view, and he seems to have had success building robust, stable software
using this approach. Now, I'm not saying that this should be PHP's
approach. I recently presented the idea of having a scalar type (with
aliases) because this could identify problems the first time a PHP file is
parsed rather than at runtime. However, I do bring up Joe Armstrong's
approach to temper the belief that casting or something less is too
forgiving.
I am interested in adding some type of ability to PHP to catch
RE: [PHP-DEV] Scalar Type Hinting
From: Adam Jon Richardson [mailto:adamj...@gmail.com]
I don't think it's fair to say that casting is too forgiving OR
that current sentiment is settling around behavior similar to the
internal zend_parse_parameters. This is a complex issue, and there
are many core developers who have been focusing on other things
besides this discussion. Their silence likely does not demonstrate
sentiment of approval for anything at this point. This particular
subject has much history on the PHP mailing list, and the opinions
are far ranging. More importantly, this general subject has much
history in all of the programming languages that are dynamically
typed.
Sorry, you misunderstood. What I meant was *not* that core developers had
bought into this (whether that will happen is unknown.) I meant that the
discussion in this thread among the most active participants appeared to shift
hard this direction as soon as it was proposed (can't remember who by.) Taken
in the context of everything else it was a good foundation that solved a number
of problems all at once.
Let's look at the examples you gave:
(function(int){})('1'); // no error, function gets (int)1
(function(int){})('123xyz'); // E_NOTICE, function gets (int)123
(function(int){})('xyz'); // E_WARNING, function gets (int)0
I'm wondering where you would be getting the values '123xyz' and 'xyz' from
at runtime...
It doesn't so much matter where it comes from or why. The spec has to define
how such inputs are handled (the behavior can't be undefined). E_NOTICE and
E_WARNING matches a behavior that we know has already been considered
acceptable in the core (I.E. this is the behavior of substr()).
Joe Armstrong, creator of the dynamically typed Erlang language,
advocates performing checks on the datatypes at the points in the
application that receive input, but not within the internal functions.
It's an interesting view, and he seems to have had success building
robust, stable software using this approach.
I tend to agree, but this sort of argument hasn't held much sway in the past on
the typing issue in PHP so in terms of designing a viable RFC that can pass a
vote I don't see that it matters much what we think here.
Now, I'm not saying that this should be PHP's approach. I recently
presented the idea of having a scalar type (with aliases) because
this could identify problems the first time a PHP file is parsed
rather than at runtime. However, I do bring up Joe Armstrong's
approach to temper the belief that casting or something less is
too forgiving.
At least for me, script inputs are far less important than other stuff; for
example, generating good errors after a refactoring mistake. Allowing
everything to pass through without errors solves the documentation issue, but
basically nothing else.
I very much enjoyed seeing someone as skilled as Anthony crank out
a quick proof-of-concept (I'd still be sifting through Zend's
internals trying to get out of my Objective-C mode of thinking.)
Yes, huge thanks for Anthony's contributions here.
I just hope that we look at all options (including doing nothing),
consider the research already done on dynamic type systems, and look
to examples in other programming languages that can give us insights
into what works well and what doesn't.
Adam
Agreed. I've been advocating the collection and organization of information
from prior discussions for a while. If there is good stuff to learn from
discussions in similar languages we should look over that too. The primary
barrier I see here is time. Looking over all this will take a lot of work.
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Hinting
Stas Malyshev wrote: And can we please stop using word hinting? We can call it type conversion, typecasting, type coercion, etc. http://en.wikipedia.org/wiki/Type_conversion But I don't see how there's any hinting involved. Is this were things have drifted from the original working base? I was under the impression that the idea was to give developers a nudge as to what type of parameter was required ( so documentation did the job for me ) rather than forcing a conversion when the wrong type was supplied? Which particular problem is being worked on? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Hinting
Hi,
I'm with Stas here.
First let me say that I would like to see type hinting for scalars in
PHP. As a userland developer it would help me to write clean and more
robust code. But I think this proposal is only a workaround to get a
round the main problem. It's a try to push similar functionality into
PHP without breaking BC. I think it's the wrong way.
Anthony, You addressed one of the main issues in your last post.
Again, I personally see casting data-loss a bigger issue than just
parameter hinting, which should get its own RFC to clean up. That's
why I didn't include it here. On purpose...
Why not try to change this first?
I know there are more issues to solve. But I think only solving issue
piece by piece, regardless if BC breaks, brings a robust and clean
implementation of this feature. Not immediately, maybe in the next major
version.
Just my 2 cents.
Christian
Am 07.03.2012 08:31, schrieb Stas Malyshev:
Hi!
https://wiki.php.net/rfc/parameter_type_casting_hints
Just took a look on it - the syntax proposed there is quite ugly and
rather confusing, I really wouldn't like to have such syntax in PHP.
Also (int) $foo = “1” will generate an E_COMPILE_ERROR makes no
sense to me.
Also, this line:
function test((int) $intParam, (string) $strParam = foo, (array)
$array) {}
is not proper PHP code - it contains optional parameter and then
parameter with no default.
And can we please stop using word hinting?
We can call it type conversion, typecasting, type coercion, etc.
http://en.wikipedia.org/wiki/Type_conversion
But I don't see how there's any hinting involved.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Hinting
Stas,
Thanks for the comments!
inline.
On Wed, Mar 7, 2012 at 2:31 AM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
https://wiki.php.net/rfc/parameter_type_casting_hints
Just took a look on it - the syntax proposed there is quite ugly and rather
confusing, I really wouldn't like to have such syntax in PHP.
Ok, this is where I'm torn. I have a few (read: about 4 or 5)
responses (mostly from people I respect quite a bit) that say it's
quite ugly and confusing. I have had a lot more responses saying it's
simple, elegant and syntatically draws the difference between casting
and strict type checking. I see your point, I really do. It's not
the prettiest syntax out there. But confusing? I'm not so sure... I
think you're too close to the problem to really understand it. Or
perhaps I am... I don't know.
But based on the conversations I've had with all sorts of devs about
this (some that I don't know personally, some that I do, some junior,
some senior), the vast majority of them got it without explanation.
The fact that cast syntax was re-used gave them enough of a hint as to
what it was doing that they guessed correctly. Now, if you think it
should be doing something different, then definitely re-visit the
syntax. But if it's going to be casting variables, the syntax does
make sense and carries an intrinsic value with it...
Also (int) $foo = “1” will generate an E_COMPILE_ERROR makes no sense to
me.
Actually, that makes perfect sense to me. Think about it from the
reader perspective. Sure, (int) $foo = '1' is pretty straight
forward, but what you you think if you saw:
foo ((string) $bar = 123);
Frankly, that would confuse the daylights out of me, and would force
me to stop and think about what would happen. That's exactly what I
would like to avoid, the thinking step on reading it. In fact, it
would make even less sense, since it would need to be cast, so the
following would return false:
function foo((string) $bar = 123) {
return $bar === 123;
}
foo();
How much more confusing is that? By restricting the default parameter
to be of the type being casted to, that sort of a problem wouldn't
happen and would be adverted by the compiler...
I think the difference is that I know that strings are not integers
and vise versa. Even at the language level there are subtle
differences in behavior between the types, even if they store
equivalent values.
Also, this line:
function test((int) $intParam, (string) $strParam = foo, (array) $array)
{}
is not proper PHP code - it contains optional parameter and then parameter
with no default.
It is proper PHP code. It parses just fine
(http://codepad.viper-7.com/rEHqZp). Sure, it's not best practice
(and was an accident which has been fixed), but it's 100% valid and
proper PHP code and doesn't even raise E_STRICT errors...
And can we please stop using word hinting?
We can call it type conversion, typecasting, type coercion, etc.
http://en.wikipedia.org/wiki/Type_conversion
Well, but I think that a distinction needs to be made about where it
is. How about Parameter Casting. Better?
But I don't see how there's any hinting involved.
The compiler (and any IDE) knows what the type of the variable will be
inside the function body. How is that not hinting?
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Hinting
Christian, On Wed, Mar 7, 2012 at 3:22 AM, Christian Kaps christian.k...@mohiva.com wrote: Hi, I'm with Stas here. First let me say that I would like to see type hinting for scalars in PHP. As a userland developer it would help me to write clean and more robust code. But I think this proposal is only a workaround to get a round the main problem. It's a try to push similar functionality into PHP without breaking BC. I think it's the wrong way. Again, the lack of a BC break is a side-effect of the main limiting factor which was to allow for stricter checks in the future and keep some semblance of a sensible syntax (having foo(int $foo) allow foo(5) makes a lot less sense to me)... Anthony, You addressed one of the main issues in your last post. Again, I personally see casting data-loss a bigger issue than just parameter hinting, which should get its own RFC to clean up. That's why I didn't include it here. On purpose... Why not try to change this first? The simple reason, is that I was under the impression that one or more devs were writing that proposal. I was going to let them. If they have stopped, or want my help, or want me to do it, I'm all for that... Thanks, Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Hinting
I, for one, decided not to participate in the discussions any more
because they always change to something different in a few hours of
discussion. I'm surprised how people tend to complicate the feature
into something weird and ugly. I now understand why core team just
ignores some discussions.
I don't like the function a( (int) $int) syntax and approach - it's
not type hinting, it's auto-converting arguments. And adding function
a( (array) $array) is just, well, pointless. Why? Because if you have
a conversion from scalar to array - you definitely have something
wrong in the code that needs fixing, not converting and continue to
run the code like it's OK. It should come like a barrier, not a
filter. And current array and object type hinting does just that. The
(object) is also pointless for type hinting. Why? Because you usually
expect not any damn object, but an object of certain type and it's
children. That works now just fine and errors the hell out if
something isn't right.
I realize that with scalars it's not that straight forward, but
complicating things by adding an auto-cast syntax and so on is just
ridiculous. Hints should stay, well, hints. The only problem we have
is complications of accepting numerical strings or numbers as strings.
And what to do with null. Everything else is irrelevant.
function a(bool $bool) {}
a(10); // Kill your self against the wall - write a(true);
If you define bool - use the damn bool! It's not an if or switch
statement where auto-converting is usually used. It's a function call,
you should pass to it correct arguments. Type hinting is working only
for more internal API's - the data filtering and validating layer
using type hints will generate errors all over the place. We all know
how many security hole scanners out there that scan sites and pass all
kind of data to our scripts to break them and try exploiting that.
I consider interchangeable only three cases:
1. Numerical string.
2. Integers and floats as strings.
3. Integer and string 0 1 as bool.
Any other cases should error out.
Type hinting is not for using it all over the place - it should be
used in places it is really needed. And it should define the expected
type with some auto-converting limited special cases like I have
written above. That is really all it needs. No
super-duper-auto-converting type-hints, no variable type hinting and
other wild stuff I have seen during last 2-3 weeks.
Anything more complicated than that and count a -1 vote from me.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Hinting
Comment in-line below... On Wednesday, March 07, 2012 07:10 AM, Simon Schick wrote: Hi,: It got quite around that because we have some RFCs to this where the functionality seems to be defined as the people thought it should be. Otherwise they can raise their hands and write a mail that they want to update the RFC - but as there's no one doing that, I think we're quite close to what we wanted. Take a look at it and feel free to add your ideas in this thread. https://wiki.php.net/rfc/parameter_type_casting_hints https://wiki.php.net/rfc/object_cast_to_types Been watching this for a while, got slightly interested in the parameter casting thing, but then ran a little test http://www.roojs.com/examples/types.php Casting on PHP may help the code inside the function, but the result is some weird and wonderful magic for the calling code, not to mention that the docs for (int) casting say the behavior may change, don't expect it to work like that forever.. You could try some kind of stricter casting. Where odd conversions between array/object - bool/int/float/string do not work on parameter casting .. but then you end up with two types of casting ... Anyway, will go back to lurking for a while.. Regards Alan Bye Simon 2012/3/6 Kris Craigkris.cr...@gmail.com Wow no offense, but your timing is terrible, Raymond! We've been going back and forth on this for the past couple weeks now, though the discussion has quieted for the moment. I would suggest you go through some of the recent posts on Internals. Right now there basically is no solid consensus on this issue, though some of us have been working to change that. But as it stands now, I'm not aware of any plans to introduce expanded typing of any kind in the foreseeable future. And even if we did, I highly doubt it would happen before PHP 6. --Kris On Mon, Mar 5, 2012 at 6:20 PM, Raymond Irvingxwis...@gmail.com wrote: Hello, I came across some info on the web that states that scalar type hinting was added to the PHP trunk but it did not make it's way into 5.4 because of objections from the community. Will it ever make it's way into 5.5? I know PHP is considered to be a weak typed language but it should also be about freedom. Freedom for a PHP developer to choose to use scalar type hinting whenever he/she sees the need. Best regards, __ Raymond -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Hinting
You could try some kind of stricter casting. Where odd conversions
between array/object - bool/int/float/string do not work on parameter
casting .. but then you end up with two types of casting ...
I have used in depth the casting operators of C#, which are incredibly
flexible and powerful, and they are based on this exact idea. In C#, there
are two types of casting: implicit and explicit. The first is used for
trivial conversions and the later for the odd ones. It is possible to
classify PHP's casts into these two categories:
int to string: implicit
int to float: implicit
int to object: explicit
int to array: explicit
...
Once this classification is done, the code becomes much more sane. Examples:
function test_float( float test ) { ... }
test_float( 1.0 ); // ok
test_float( 1 );// implicit int to float cast, ok
function test_array( array test ) { ... }
test_array( array() ); // ok
test_array( 1 );// no implicit int to array cast, error!
test_array( (array)1 ); // explicit int to array cast, ok
I deliberately avoided using Anthony's cast-like syntax, because it does
not fit nicely here. Calling a function may cause an implicit cast, but it
will never do an explicit one.
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/3/7 Alan Knowles a...@akbkhome.com
Comment in-line below...
On Wednesday, March 07, 2012 07:10 AM, Simon Schick wrote:
Hi,:
It got quite around that because we have some RFCs to this where the
functionality seems to be defined as the people thought it should be.
Otherwise they can raise their hands and write a mail that they want to
update the RFC - but as there's no one doing that, I think we're quite
close to what we wanted.
Take a look at it and feel free to add your ideas in this thread.
https://wiki.php.net/rfc/parameter_type_casting_hints
https://wiki.php.net/rfc/object_cast_to_types
Been watching this for a while, got slightly interested in the parameter
casting thing, but then ran a little test
http://www.roojs.com/examples/types.php
Casting on PHP may help the code inside the function, but the result is
some weird and wonderful magic for the calling code, not to mention that
the docs for (int) casting say the behavior may change, don't expect it to
work like that forever..
You could try some kind of stricter casting. Where odd conversions between
array/object - bool/int/float/string do not work on parameter casting ..
but then you end up with two types of casting ...
Anyway, will go back to lurking for a while..
Regards
Alan
Bye
Simon
2012/3/6 Kris Craigkris.cr...@gmail.com
Wow no offense, but your timing is terrible, Raymond! We've been going
back and forth on this for the past couple weeks now, though the
discussion
has quieted for the moment.
I would suggest you go through some of the recent posts on Internals.
Right now there basically is no solid consensus on this issue, though
some
of us have been working to change that. But as it stands now, I'm not
aware of any plans to introduce expanded typing of any kind in the
foreseeable future. And even if we did, I highly doubt it would happen
before PHP 6.
--Kris
On Mon, Mar 5, 2012 at 6:20 PM, Raymond Irvingxwis...@gmail.com
wrote:
Hello,
I came across some info on the web that states that scalar type hinting
was
added to the PHP trunk but it did not make it's way into 5.4 because of
objections from the community. Will it ever make it's way into 5.5?
I know PHP is considered to be a weak typed language but it should also
be
about freedom. Freedom for a PHP developer to choose to use scalar type
hinting whenever he/she sees the need.
Best regards,
__
Raymond
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Hinting
Hi!
would make even less sense, since it would need to be cast, so the
following would return false:
function foo((string) $bar = 123) {
return $bar === 123;
}
foo();
You explicitly said convert, then compare excluding conversion, what
would you expect? That's like saying why $a+1 is not equal to $a, it's
almost the same?. No it's not - you just told PHP to modify it!
How much more confusing is that? By restricting the default parameter
to be of the type being casted to, that sort of a problem wouldn't
happen and would be adverted by the compiler...
I feel you're painting yourself into a corner here - inventing arbitrary
restrictions and then inventing arbitrary problems to justify these
restrictions. Why would your conversion convert, but not always convert?
Why it would work with constants, but not in defaults?
It is proper PHP code. It parses just fine
(http://codepad.viper-7.com/rEHqZp). Sure, it's not best practice
The fact it parses doesn't mean it is proper code. The fact it's not
errors out is actually a bug, as such function definition is broken. But
let's not take the discussion too far out - just please do not promote
such code in our RFCs.
The compiler (and any IDE) knows what the type of the variable will be
inside the function body. How is that not hinting?
Hinting means something that is just for information and can be ignored
it you don't need it. This is type coercion - you can not ignore it, it
would change your variables. Calling it hinting implies it does not do
anything, just informs IDE - that'd what PHPDoc does, but that's not
what your proposed function does. Proper naming is important.
The compiler BTW doesn't know anything and has no way to know it and
benefit from it in any way.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Scalar Type Hinting
From: Anthony Ferrara [mailto:ircmax...@gmail.com]
John,
On Tue, Mar 6, 2012 at 9:04 PM, John Crenshaw johncrens...@priacta.com
wrote:
A good number of issues with the current proposal were raised during the
discussion on the mailing list. I don't feel like digging them all up right
now, but off the top of my head I remember the following being raised and
never saw any consensus for how to resolve them:
I went over the replies to the initial POC thread that I posted
(http://marc.info/?t=13306603721r=1w=2) and I'll rebut your replies.
You've been spending a lot of time defending these proposals and trying to
prove wrong feedback that raises concerns. This is preventing you from actually
using the feedback to improve the proposals. You are losing out on perhaps the
biggest advantage of the RFC process, which is that multiple minds can work
together to hammer out an idea and make it really shine.
Most of your rebuttals focus entirely on whether the RFC contains sufficient
information to make something technically work. That's not the point at all.
I've read the RFC. I have no doubt that it works, nor I think does anyone
else. That's not the issue.
To quote a recent film: Titan: Oh yeah? What's the difference? Megamind:
PRESENTATION!. The code syntax is the UI that PHP presents to developers. Yes,
this works (in the sense that it is possible to implement what the RFC
describes), but there are serious usability and communication problems.
Language is also one of the trickiest interfaces to work with because once you
commit to something you are pretty much stuck with it forever (namespace
separator). If every PHP developer is going to have to deal with this until the
end of time it needs to be *awesome*.
- inconsistent syntax (one syntax for scalars, a different one for
classes)
This is actually discussed in the RFC, as it is not inconsistent (it's
actually consistent with what the patch tries to achieve). The syntax for
classes and normal arrays is a strict check, where if the match fails an
error is thrown. This syntax attempts to distinguish between that
functionality by providing a different syntax altogether. And since it's
casting the parameters, the syntax feels natural (for that goal).
You can mince words, but that doesn't change the problem. It is utterly
inconsistent with the expectations in creates. You'll argue that it creates an
expectation of a type cast, but you'd be wrong in far too many cases. The
syntax is similar enough to the syntax for parameter types in other languages
that developers will think of it as basically the same thing. The syntax
differs however from existing parameter type syntax.
The behavioral difference is also a problem, being too different from parameter
typing to be useful (it doesn't actually vet the parameter), and yet close
enough to validate the confusion (behaves too similarly to an implicit
conversion). In the end you have a bizarre syntax that looks like one thing but
is conceptually another, but with a subtle behavioral difference that is
invisible except when it fails to fail.
- conflicting syntax (I.E. array vs. (array), RFC simply allows
this, and ignores the confusion that this will create for users.)
Actually, it doesn't simply allow that. It did it for a very specific
reason. array is a strict check, and (array) is a casting check.
One will fatal if a non-array is passed, and the other will attempt to
convert the parameter to an array. Very different functionality, which are
both internally consistent with the other syntax...
I know about the behavioral difference. I'm not talking about a technical
conflict, I'm talking about a conflict in the mind of the developer. Given
function(array $a, (array) $b){} the difference between $a and $b is a very
advanced distinction and will be completely lost by the average developer.
The confusion is made worse by the fact that function(array $a) works, but
function(int $a) doesn't, but function((int) $a) does. I know why, but the
average developer just learning PHP for the first time won't get it at all.
- different from the syntax used in the docs
Actually, it's the exact same syntax used for casting in the docs.
It's different from class type hints, because it's intended to be so.
If you don't like it, that's fine. But it's intentionally different.
Sometimes I think you miss the point on purpose.
In the docs substr is defined as:
string substr ( string $string , int $start [, int $length ] )
If I wanted to write the same thing in my own code I would have to write:
function my_substr ( (string) $string , (int) $start , (int) $length )
One syntax for the docs, a different one in my code.
- lack of sufficient function to justify a core change
That's absolutely something to be considered. However, I see erroring on
invalid casts as a bigger issue not the responsibility of a
**casting** hint patch.
Re: [PHP-DEV] Scalar Type Hinting
Hi Arvids,
I pretty much like this idea as it's more strict. Let me say something
to the questions you pointed out here.
2012/3/7 Arvids Godjuks arvids.godj...@gmail.com:
I realize that with scalars it's not that straight forward, but
complicating things by adding an auto-cast syntax and so on is just
ridiculous. Hints should stay, well, hints. The only problem we have
is complications of accepting numerical strings or numbers as strings.
And what to do with null.
I'd like to handle it the same way as it's handled with the classes
right now. If null is not the default-value you'll get an error when
you pass null in there.
One thing I'd like opened here: If you define a default-value
different than null, should you be able to pass null as well and the
compiler will use the default-value?
function a(bool $bool) {}
a(10); // Kill your self against the wall - write a(true);
If you define bool - use the damn bool!
I like that. What should we do if this appears? As it's now - just
throw an Catchable fatal error and let the script blow-up? I would
go this far.
I consider interchangeable only three cases:
1. Numerical string.
2. Integers and floats as strings.
3. Integer and string 0 1 as bool.
Any other cases should error out.
Until now I thought about the weak variable-types as a order ...
string, float, integer, Boolean.
All Boolean values are compatible be an integer (0 or 1) and all
integer are compatible to a float and so on. Do you think it's good to
have it this way? This would mean that you could also get a Boolean
true as string 1 ... I personally don't like that ... but I don't
know where to draw the strict-line.
Now think about that backwards. Can a 1 be passed as a parameter
that expects Boolean? If yes, I'd keep it consistent in both ways.
Bye
Simon
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Hinting
John,
Thanks a lot for the reply. Comments inline:
You've been spending a lot of time defending these proposals and trying to
prove wrong feedback that raises concerns. This is preventing you from
actually using the feedback to improve the proposals. You are losing out on
perhaps the biggest advantage of the RFC process, which is that multiple
minds can work together to hammer out an idea and make it really shine.
I only defended what I thought were misconceptions or miss-information
about them. After all, the quickest way to a failure is assumption
(granted, this is ironic given the rest of this reply)...
You can mince words, but that doesn't change the problem. It is utterly
inconsistent with the expectations in creates. You'll argue that it creates
an expectation of a type cast, but you'd be wrong in far too many cases. The
syntax is similar enough to the syntax for parameter types in other languages
that developers will think of it as basically the same thing. The syntax
differs however from existing parameter type syntax.
That was intentional. That was the point I was trying to make... But
let's keep going.
The behavioral difference is also a problem, being too different from
parameter typing to be useful (it doesn't actually vet the parameter), and
yet close enough to validate the confusion (behaves too similarly to an
implicit conversion). In the end you have a bizarre syntax that looks like
one thing but is conceptually another, but with a subtle behavioral
difference that is invisible except when it fails to fail.
Again, up to this point, this fits in with what was intended...
I know about the behavioral difference. I'm not talking about a technical
conflict, I'm talking about a conflict in the mind of the developer. Given
function(array $a, (array) $b){} the difference between $a and $b is a very
advanced distinction and will be completely lost by the average developer.
I actually think that it's not that advanced of a distinction, but
agree to disagree there.
The confusion is made worse by the fact that function(array $a) works, but
function(int $a) doesn't, but function((int) $a) does. I know why, but the
average developer just learning PHP for the first time won't get it at all.
I won't argue that, but I would make the assertion that there are far
more dangerous things that PHP does that the average developer just
learning PHP won't get. But again, let's go on...
Sometimes I think you miss the point on purpose.
In the docs substr is defined as:
string substr ( string $string , int $start [, int $length ] )
If I wanted to write the same thing in my own code I would have to write:
function my_substr ( (string) $string , (int) $start , (int) $length )
One syntax for the docs, a different one in my code.
Now, finally we get to a solid point. I didn't make the connection to
the parameter hinting in the docs that you meant. You said syntax in
the docs, and I was thinking about the casting syntax, which is why I
asserted that both the syntax and the behavior are inline with the
docs.
We were both right, just talking about very different things.
Now, with that said, I completely see your point.
Well, if you argue that this proposal is actually a typecasting enhancement
and not a parameter type enhancement, then yes, you'd be right. That's not
how this is presented though, that's not where it is presented (Scalar Type
Hinting discussion), that's not when it was presented, and that's not how it
is getting perceived or measured.
Well, I think that's part of the problem here. People (including both
you and me) have so much vested in this discussion, that they are
reading things into the proposal that aren't there (both in a good
way, and a bad way).
As far as expanding type casting in this way, it doesn't make sense. There is
no precedent, it looks and will get treated like parameter hinting (which you
are saying it isn't), there is no additional functional value, and very
little value of any sort beyond casts (just a tiny documentation boost and a
savings in the number of characters in the few cases where a dumb type cast
is good enough.)
Well, I think there's a bit more to be gained on both the static
analysis front and the IDE integration front. Additionally, defensive
coding now only needs to worry about 1 type, and it puts the onus to
ensure proper results on the caller (which is where I would argue it
belongs)...
Again, yes, I know that the RFC takes a position on this. My point is not
that the RFC doesn't take a position, my point was that the position taken
ignores the need that would have caused this sort of code in the first
place.
It took a position, because there seemed to be a fair bit of concensus
on the list (in current and past dicussions) that this sort of thing
should explicitly disallow references. I haven't seen much to the
opposite until:
Reference parameters are basically
Re: [PHP-DEV] Scalar Type Hinting
Hi,
Just a small addition to what I wrote about handling null ...
function foo(array $d = array()) { var_dump($d); }
foo(null); // This fails with the message: Argument 1 passed to foo()
must be an array, null given
As this code fails I'd not expect to change this behavior for the weak-types.
function foo(int $d = 20) { var_dump($d); }
foo(null); // This should then also fail. Don't care about what's the
default-value.
Bye
Simon
2012/3/8 Simon Schick simonsimc...@googlemail.com:
Hi Arvids,
I pretty much like this idea as it's more strict. Let me say something
to the questions you pointed out here.
2012/3/7 Arvids Godjuks arvids.godj...@gmail.com:
I realize that with scalars it's not that straight forward, but
complicating things by adding an auto-cast syntax and so on is just
ridiculous. Hints should stay, well, hints. The only problem we have
is complications of accepting numerical strings or numbers as strings.
And what to do with null.
I'd like to handle it the same way as it's handled with the classes
right now. If null is not the default-value you'll get an error when
you pass null in there.
One thing I'd like opened here: If you define a default-value
different than null, should you be able to pass null as well and the
compiler will use the default-value?
function a(bool $bool) {}
a(10); // Kill your self against the wall - write a(true);
If you define bool - use the damn bool!
I like that. What should we do if this appears? As it's now - just
throw an Catchable fatal error and let the script blow-up? I would
go this far.
I consider interchangeable only three cases:
1. Numerical string.
2. Integers and floats as strings.
3. Integer and string 0 1 as bool.
Any other cases should error out.
Until now I thought about the weak variable-types as a order ...
string, float, integer, Boolean.
All Boolean values are compatible be an integer (0 or 1) and all
integer are compatible to a float and so on. Do you think it's good to
have it this way? This would mean that you could also get a Boolean
true as string 1 ... I personally don't like that ... but I don't
know where to draw the strict-line.
Now think about that backwards. Can a 1 be passed as a parameter
that expects Boolean? If yes, I'd keep it consistent in both ways.
Bye
Simon
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Scalar Type Hinting
Now we understand each other fully... Point taken. I've withdrawn the parameter hinting RFC. Thanks...and aw crap. I hate feeling like I shut the door on something. Let's make sure we can salvage as much as possible here: 1. The structure of the patch looked like it was reusable regardless of whether the final syntax used a typename of a cast, right? Let's not lose that. 2. Examining parameters from this perspective gave some good insight into the behavior of the system when implicitly converting inputs. I truely thank you for helping me understand your concerns. I only wish they could have been shared more clearly at the POC phase so we could have avoided this altogether... Thanks, Anthony I'm sorry for not raising the concerns well enough earlier. John Crenshaw Priacta, Inc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Hinting
John, Thanks...and aw crap. I hate feeling like I shut the door on something. Not at all. I don't feel bad about this in the least. Yes, I would have liked to have gotten it in, but I want a good solution before I want mine. So I'm absolutely willing to withdraw this RFC, as it does have issues. And it's not really shutting the door. It's moving a roadblock over so that another (hopefully better) proposal can take its place... Let's make sure we can salvage as much as possible here: 1. The structure of the patch looked like it was reusable regardless of whether the final syntax used a typename of a cast, right? Let's not lose that. Yeah, there was some in there that I definitely learned from. Including that the casting logic in the core is really in bad shape (it's everywhere!). 2. Examining parameters from this perspective gave some good insight into the behavior of the system when implicitly converting inputs. Oh, doing the RFC and the patch definitely had value. It's not like it's lost effort (and the reference is on the wiki still). And I'm glad I did a finalized patch, since it showed that some API change (on C level) would be necessary (namely the argument parsing function, to accept a double-pointer instead of a single one). I'm sorry for not raising the concerns well enough earlier. You did. We just didn't connect and understand each other (or I didn't understand you) earlier. But that's behind. Let's move up and on... So, that leaves the question: where to go next... (I have a somewhat radical proposal that I'd like to make to list that's somewhat releated, but I'm going to think it out first before posting)... Thanks again, Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Scalar Type Hinting
From: Simon Schick [mailto:simonsimc...@googlemail.com] I consider interchangeable only three cases: 1. Numerical string. 2. Integers and floats as strings. 3. Integer and string 0 1 as bool. Any other cases should error out. Until now I thought about the weak variable-types as a order ... string, float, integer, Boolean. All Boolean values are compatible be an integer (0 or 1) and all integer are compatible to a float and so on. Do you think it's good to have it this way? This would mean that you could also get a Boolean true as string 1 ... I personally don't like that ... but I don't know where to draw the strict-line. Now think about that backwards. Can a 1 be passed as a parameter that expects Boolean? If yes, I'd keep it consistent in both ways. Bye Simon Conversion the other way is essential. Consider the following URL: http://example.com?foo=1 In your PHP script $_GET['foo'] === '1' (a string). In fact, nearly every input to PHP is a string. This is why PHP was designed with some seriously robust type juggling on scalars. Any typing proposal that wants to actually pass a vote is going to have to allow appropriate implicit conversions from string to other types. John Crenshaw Priacta, Inc.
Re: [PHP-DEV] Scalar Type Hinting
On 3/7/2012 8:48 PM, John Crenshaw wrote: In fact, nearly every input to PHP is a string. This is why PHP was designed with some seriously robust type juggling on scalars. Any typing proposal that wants to actually pass a vote is going to have to allow appropriate implicit conversions from string to other types. In fact, nearly every output from PHP is a string. Also why PHP was designed with some seriously robust type juggling on scalars. Any typing proposal that wants to actually pass a vote is going to have to allow appropriate implicit conversions to string from other types. $x = 1.8; $y = 2.3; list( $int, $fract ) = explode( '.', $x + $y ); -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Hinting
2012/3/8 John Crenshaw johncrens...@priacta.com: Conversion the other way is essential. Consider the following URL: http://example.com?foo=1 In your PHP script $_GET['foo'] === '1' (a string). In fact, nearly every input to PHP is a string. This is why PHP was designed with some seriously robust type juggling on scalars. Any typing proposal that wants to actually pass a vote is going to have to allow appropriate implicit conversions from string to other types. John Crenshaw Priacta, Inc. Hi, John Ok .. the example with the get-parameter is quite good. You'll often have the case that you submit a string 0 or 1 and want to have it as boolean (f.e. if you have a dropdown with two options). Please keep in mind not to mix it up with checkboxes as unchecked checkboxes won't be sent back to your webserver :) Bye Simon -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Hinting
Hi, It got quite around that because we have some RFCs to this where the functionality seems to be defined as the people thought it should be. Otherwise they can raise their hands and write a mail that they want to update the RFC - but as there's no one doing that, I think we're quite close to what we wanted. Take a look at it and feel free to add your ideas in this thread. https://wiki.php.net/rfc/parameter_type_casting_hints https://wiki.php.net/rfc/object_cast_to_types Bye Simon 2012/3/6 Kris Craig kris.cr...@gmail.com Wow no offense, but your timing is terrible, Raymond! We've been going back and forth on this for the past couple weeks now, though the discussion has quieted for the moment. I would suggest you go through some of the recent posts on Internals. Right now there basically is no solid consensus on this issue, though some of us have been working to change that. But as it stands now, I'm not aware of any plans to introduce expanded typing of any kind in the foreseeable future. And even if we did, I highly doubt it would happen before PHP 6. --Kris On Mon, Mar 5, 2012 at 6:20 PM, Raymond Irving xwis...@gmail.com wrote: Hello, I came across some info on the web that states that scalar type hinting was added to the PHP trunk but it did not make it's way into 5.4 because of objections from the community. Will it ever make it's way into 5.5? I know PHP is considered to be a weak typed language but it should also be about freedom. Freedom for a PHP developer to choose to use scalar type hinting whenever he/she sees the need. Best regards, __ Raymond
Re: [PHP-DEV] Scalar Type Hinting
My concern is the total lack of talk on-list about it. It's obviously not perfect, but there has been little to no talk on-list about it. That is an indication to me that it's not ready or that it won't get in if put to a vote... Thoughts? Anthony On Tue, Mar 6, 2012 at 6:10 PM, Simon Schick simonsimc...@googlemail.com wrote: Hi, It got quite around that because we have some RFCs to this where the functionality seems to be defined as the people thought it should be. Otherwise they can raise their hands and write a mail that they want to update the RFC - but as there's no one doing that, I think we're quite close to what we wanted. Take a look at it and feel free to add your ideas in this thread. https://wiki.php.net/rfc/parameter_type_casting_hints https://wiki.php.net/rfc/object_cast_to_types Bye Simon 2012/3/6 Kris Craig kris.cr...@gmail.com Wow no offense, but your timing is terrible, Raymond! We've been going back and forth on this for the past couple weeks now, though the discussion has quieted for the moment. I would suggest you go through some of the recent posts on Internals. Right now there basically is no solid consensus on this issue, though some of us have been working to change that. But as it stands now, I'm not aware of any plans to introduce expanded typing of any kind in the foreseeable future. And even if we did, I highly doubt it would happen before PHP 6. --Kris On Mon, Mar 5, 2012 at 6:20 PM, Raymond Irving xwis...@gmail.com wrote: Hello, I came across some info on the web that states that scalar type hinting was added to the PHP trunk but it did not make it's way into 5.4 because of objections from the community. Will it ever make it's way into 5.5? I know PHP is considered to be a weak typed language but it should also be about freedom. Freedom for a PHP developer to choose to use scalar type hinting whenever he/she sees the need. Best regards, __ Raymond -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Hinting
Personally, speaking for myself at least, I've quieted on the subject temporarily in favor of advocating some improvements to the RFC voting process that will ultimately make it easier for us to work through these type hinting questions. I'll be resurrecting the discussion on this end before too long. =) --Kris On Tue, Mar 6, 2012 at 3:35 PM, Anthony Ferrara ircmax...@gmail.com wrote: My concern is the total lack of talk on-list about it. It's obviously not perfect, but there has been little to no talk on-list about it. That is an indication to me that it's not ready or that it won't get in if put to a vote... Thoughts? Anthony On Tue, Mar 6, 2012 at 6:10 PM, Simon Schick simonsimc...@googlemail.com wrote: Hi, It got quite around that because we have some RFCs to this where the functionality seems to be defined as the people thought it should be. Otherwise they can raise their hands and write a mail that they want to update the RFC - but as there's no one doing that, I think we're quite close to what we wanted. Take a look at it and feel free to add your ideas in this thread. https://wiki.php.net/rfc/parameter_type_casting_hints https://wiki.php.net/rfc/object_cast_to_types Bye Simon 2012/3/6 Kris Craig kris.cr...@gmail.com Wow no offense, but your timing is terrible, Raymond! We've been going back and forth on this for the past couple weeks now, though the discussion has quieted for the moment. I would suggest you go through some of the recent posts on Internals. Right now there basically is no solid consensus on this issue, though some of us have been working to change that. But as it stands now, I'm not aware of any plans to introduce expanded typing of any kind in the foreseeable future. And even if we did, I highly doubt it would happen before PHP 6. --Kris On Mon, Mar 5, 2012 at 6:20 PM, Raymond Irving xwis...@gmail.com wrote: Hello, I came across some info on the web that states that scalar type hinting was added to the PHP trunk but it did not make it's way into 5.4 because of objections from the community. Will it ever make it's way into 5.5? I know PHP is considered to be a weak typed language but it should also be about freedom. Freedom for a PHP developer to choose to use scalar type hinting whenever he/she sees the need. Best regards, __ Raymond
RE: [PHP-DEV] Scalar Type Hinting
Hi, It got quite around that because we have some RFCs to this where the functionality seems to be defined as the people thought it should be. Otherwise they can raise their hands and write a mail that they want to update the RFC - but as there's no one doing that, I think we're quite close to what we wanted. Take a look at it and feel free to add your ideas in this thread. https://wiki.php.net/rfc/parameter_type_casting_hints https://wiki.php.net/rfc/object_cast_to_types Bye Simon Sorry, I disagree. This is nowhere close IMO, and silence doesn't denote consent in this case. I actually basically stopped participating when it became apparent that people were determined to rush head first into creating a doomed RFC without any process to ensure that historical arguments were considered and addressed, with minimal attention to feedback, and with no concern for syntax (proposed syntax is as bad as the namespace syntax). I'm in favor of addressing the type hinting issue, but I'm opposed to this RFC. It is crippled, confusing, and has a plethora of unaddressed issues. The object cast has similar problems, and although I recognize the value of this sort of functionality, the current proposal seems to mostly ignore a number of critical problems that were raised when it was discussed on the mailing list. John Crenshaw Priacta, Inc.
Re: [PHP-DEV] Scalar Type Hinting
John, Sorry, I disagree. This is nowhere close IMO, and silence doesn't denote consent in this case. I actually basically stopped participating when it became apparent that people were determined to rush head first into creating a doomed RFC without any process to ensure that historical arguments were considered and addressed, with minimal attention to feedback, and with no concern for syntax (proposed syntax is as bad as the namespace syntax). Well, my take on it was that thinking out-loud in a thread is not going to get us anywhere with nothing to base the conversation on. So I picked an option and proposed it. As now, we can base the conversation around a real implementation. Don't like the syntax? Great! Let's find a better solution. But I felt that it was more important to put a base for the conversation, rather than just letting it wander aimlessly. I'm in favor of addressing the type hinting issue, but I'm opposed to this RFC. It is crippled, confusing, and has a plethora of unaddressed issues. Then point out the issues. Help improve it and make it something that *should* go in the core. That's why it's still in draft mode. I didn't propose it, or put it for discussion, I put it in draft for that very reason. As far as it being crippled, I'm not sure what you mean, just because it's only doing casting? As far as confusing, it is? I thought this was actually one of the more straight forward proposals, since it re-used so much from the core (meaning that it doesn't add new behavior, it re-uses existing behavior). As far as having a plethora of unadressed issues, I'm absolutely sure it does. But I haven't seen a single one put out there so that it can be fixed... The object cast has similar problems, and although I recognize the value of this sort of functionality, the current proposal seems to mostly ignore a number of critical problems that were raised when it was discussed on the mailing list. Which were? The critical problems that I saw on the list were mostly related to the original proposal wrapping set() with __assign() (which this proposal removed). The only known issues that I know of that remains is with the __toScalar() part (which in worst case can be removed from the proposal). These are RFCs. I am (as their author) explicitly asking for your comments and contribution. They are not set in stone in the least... In fact, the only way they would get to the point where I would propose them is with enough input and overview that it was mature. They are not mature now. Can we make them mature? Thanks, Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Scalar Type Hinting
Disclaimer: The following is direct (maybe brutally so). I'm not trying to hurt any feeling or attack, but I'm not pulling punches either. I don't have the energy right now to polish this and make it all nice and gentle, so I'm sorry in advance. I hope you'll look past the directness and be able to get some useful feedback. John, Sorry, I disagree. This is nowhere close IMO, and silence doesn't denote consent in this case. I actually basically stopped participating when it became apparent that people were determined to rush head first into creating a doomed RFC without any process to ensure that historical arguments were considered and addressed, with minimal attention to feedback, and with no concern for syntax (proposed syntax is as bad as the namespace syntax). Well, my take on it was that thinking out-loud in a thread is not going to get us anywhere with nothing to base the conversation on. So I picked an option and proposed it. As now, we can base the conversation around a real implementation. Don't like the syntax? Great! Let's find a better solution. But I felt that it was more important to put a base for the conversation, rather than just letting it wander aimlessly. Yes, it was aimless discussion (though some would call it brainstorming). It was ready to move to the next level, which should have been gathering the constraints/requirements/problems into a coherent list to work from. What happened though was that this step was skipped entirely, so now there's been an attempt to write a preliminary spec without gathering the requirements first, which IMO is far worse than any amount of aimless discussion. I'm in favor of addressing the type hinting issue, but I'm opposed to this RFC. It is crippled, confusing, and has a plethora of unaddressed issues. Then point out the issues. Help improve it and make it something that *should* go in the core. That's why it's still in draft mode. I didn't propose it, or put it for discussion, I put it in draft for that very reason. A good number of issues with the current proposal were raised during the discussion on the mailing list. I don't feel like digging them all up right now, but off the top of my head I remember the following being raised and never saw any consensus for how to resolve them: - inconsistent syntax (one syntax for scalars, a different one for classes) - conflicting syntax (I.E. array vs. (array), RFC simply allows this, and ignores the confusion that this will create for users.) - different from the syntax used in the docs - lack of sufficient function to justify a core change - chaos surrounding null (to accept and if so to cast or not? Creates a conflict between consistency and implications of the syntax) - conflicts with references (RFC tries to address this by simply disallowing references, which IMO just ignores the need that would have caused this sort of code in the first place.) There were others, but I'm not making an exhaustive list. As far as it being crippled, I'm not sure what you mean, just because it's only doing casting? Yes, casting is barely better than doing nothing. If I want a dumb typecast I can do that already. What I can't do without massive boilerplate everywhere is an intelligent conversion that accepts safe conversions and gives a warning or error on unsafe conversions. As far as confusing, it is? I thought this was actually one of the more straight forward proposals, since it re-used so much from the core (meaning that it doesn't add new behavior, it re-uses existing behavior). Yes, the syntax has some critical issues that create conflicting expectations. Look at the prior discussion. The current proposal doesn't really fix most of this. As far as having a plethora of unadressed issues, I'm absolutely sure it does. But I haven't seen a single one put out there so that it can be fixed... Again, look at the prior discussion of this syntax. Plenty of issues raised. The object cast has similar problems, and although I recognize the value of this sort of functionality, the current proposal seems to mostly ignore a number of critical problems that were raised when it was discussed on the mailing list. Which were? The critical problems that I saw on the list were mostly related to the original proposal wrapping set() with __assign() (which this proposal removed). The only known issues that I know of that remains is with the __toScalar() part (which in worst case can be removed from the proposal). The biggest one that comes to mind is behavior with respect to operators. __toScalar() in your spec is an attempt to handle this, but IMO it really doesn't cut it. Off the top of my head problems with this solution include: - This will lead to duplicated code - Thinking about my own code, I have almost no idea how I would actually write a robust __toScalar() implementation. It's still going to be
Re: [PHP-DEV] Scalar Type Hinting
John, On Tue, Mar 6, 2012 at 9:04 PM, John Crenshaw johncrens...@priacta.com wrote: Disclaimer: The following is direct (maybe brutally so). I'm not trying to hurt any feeling or attack, but I'm not pulling punches either. I don't have the energy right now to polish this and make it all nice and gentle, so I'm sorry in advance. I hope you'll look past the directness and be able to get some useful feedback. Thank you for being candid. I appreciate straight to the point replies, as long as they are respectful (which yours was very much so). So thank you. Now, to your points. Yes, it was aimless discussion (though some would call it brainstorming). It was ready to move to the next level, which should have been gathering the constraints/requirements/problems into a coherent list to work from. What happened though was that this step was skipped entirely, so now there's been an attempt to write a preliminary spec without gathering the requirements first, which IMO is far worse than any amount of aimless discussion. With all honesty, I didn't see anything being gathered. What I saw was random ideas shot back and forth (with a good bunch ignored in all the chatter). There didn't really seem to be one or two clear directions, but instead at least a dozen directions at the same time. There was talk about implementing a scalar hint, about implementing strict hints again, about implementing pseudo-casting hints that did only simple checks, about hints that actually casted, about hints that threw notices, about hints that threw warnings. There didn't seem to be anything more than a bunch of people wanting different things not even paying attention to the other conversation. Could a spec have been developed from that? Sure. Would it have? I'm not so sure. So I picked a direction that seemed consistent with as much of it as possible, and went with it. I didn't ask anyone to stop other work, or stop their discussion. I just saw an opportunity to unify the conversation around what seemed to be a commonality between the comversation, and I took it. If I stepped on anyone's toes, I'm sorry... A good number of issues with the current proposal were raised during the discussion on the mailing list. I don't feel like digging them all up right now, but off the top of my head I remember the following being raised and never saw any consensus for how to resolve them: I went over the replies to the initial POC thread that I posted (http://marc.info/?t=13306603721r=1w=2) and I'll rebut your replies. - inconsistent syntax (one syntax for scalars, a different one for classes) This is actually discussed in the RFC, as it is not inconsistent (it's actually consistent with what the patch tries to achieve). The syntax for classes and normal arrays is a strict check, where if the match fails an error is thrown. This syntax attempts to distinguish between that functionality by providing a different syntax altogether. And since it's casting the parameters, the syntax feels natural (for that goal). - conflicting syntax (I.E. array vs. (array), RFC simply allows this, and ignores the confusion that this will create for users.) Actually, it doesn't simply allow that. It did it for a very specific reason. array is a strict check, and (array) is a casting check. One will fatal if a non-array is passed, and the other will attempt to convert the parameter to an array. Very different functionality, which are both internally consistent with the other syntax... - different from the syntax used in the docs Actually, it's the exact same syntax used for casting in the docs. It's different from class type hints, because it's intended to be so. If you don't like it, that's fine. But it's intentionally different. - lack of sufficient function to justify a core change That's absolutely something to be considered. However, I see erroring on invalid casts as a bigger issue not the responsibility of a **casting** hint patch. So that's why I mention explicitly in the RFC and my blog post that solving that problem should be another RFC (culminating in a series of 3 RFCs that each work together very well to fill the overall need). - chaos surrounding null (to accept and if so to cast or not? Creates a conflict between consistency and implications of the syntax) That's absolutely a valid concern. And that's what should be being discussed, if people really feel that the current implementation is wrong... - conflicts with references (RFC tries to address this by simply disallowing references, which IMO just ignores the need that would have caused this sort of code in the first place.) Actually, it explicitly disallows references. This was added because it was explicitly requested on the list in many discussions (including the initial one for the POC). But if you can make a case on why to implement it, and why it makes sense, then we can add it back. There were others, but I'm not
Re: [PHP-DEV] Scalar Type Hinting
On 2012-03-06, Anthony Ferrara ircmax...@gmail.com wrote: My concern is the total lack of talk on-list about it. It's obviously not perfect, but there has been little to no talk on-list about it. That is an indication to me that it's not ready or that it won't get in if put to a vote... Thoughts? I really like the proposal you set forth. I have zero clue what impact it would have on performance, however, so I'm deferring that discussion to those who do. As a user and framework developer, I'd love to see it in place -- casting support at the function/method parameter level would greatly simplify a lot of code I write. On Tue, Mar 6, 2012 at 6:10 PM, Simon Schick simonsimc...@googlemail.com wrote: Hi, It got quite around that because we have some RFCs to this where the functionality seems to be defined as the people thought it should be. Otherwise they can raise their hands and write a mail that they want to update the RFC - but as there's no one doing that, I think we're quite close to what we wanted. Take a look at it and feel free to add your ideas in this thread. https://wiki.php.net/rfc/parameter_type_casting_hints https://wiki.php.net/rfc/object_cast_to_types Bye Simon 2012/3/6 Kris Craig kris.cr...@gmail.com Wow no offense, but your timing is terrible, Raymond! We've been going back and forth on this for the past couple weeks now, though the discussion has quieted for the moment. I would suggest you go through some of the recent posts on Internals. Right now there basically is no solid consensus on this issue, though some of us have been working to change that. But as it stands now, I'm not aware of any plans to introduce expanded typing of any kind in the foreseeable future. And even if we did, I highly doubt it would happen before PHP 6. --Kris On Mon, Mar 5, 2012 at 6:20 PM, Raymond Irving xwis...@gmail.com wrote: Hello, I came across some info on the web that states that scalar type hinting was added to the PHP trunk but it did not make it's way into 5.4 because of objections from the community. Will it ever make it's way into 5.5? I know PHP is considered to be a weak typed language but it should also be about freedom. Freedom for a PHP developer to choose to use scalar type hinting whenever he/she sees the need. Best regards, __ Raymond -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Hinting
Hi!
https://wiki.php.net/rfc/parameter_type_casting_hints
Just took a look on it - the syntax proposed there is quite ugly and
rather confusing, I really wouldn't like to have such syntax in PHP.
Also (int) $foo = “1” will generate an E_COMPILE_ERROR makes no sense
to me.
Also, this line:
function test((int) $intParam, (string) $strParam = foo, (array)
$array) {}
is not proper PHP code - it contains optional parameter and then
parameter with no default.
And can we please stop using word hinting?
We can call it type conversion, typecasting, type coercion, etc.
http://en.wikipedia.org/wiki/Type_conversion
But I don't see how there's any hinting involved.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Scalar Type Hinting
Hello, I came across some info on the web that states that scalar type hinting was added to the PHP trunk but it did not make it's way into 5.4 because of objections from the community. Will it ever make it's way into 5.5? I know PHP is considered to be a weak typed language but it should also be about freedom. Freedom for a PHP developer to choose to use scalar type hinting whenever he/she sees the need. Best regards, __ Raymond
Re: [PHP-DEV] Scalar Type Hinting
Wow no offense, but your timing is terrible, Raymond! We've been going back and forth on this for the past couple weeks now, though the discussion has quieted for the moment. I would suggest you go through some of the recent posts on Internals. Right now there basically is no solid consensus on this issue, though some of us have been working to change that. But as it stands now, I'm not aware of any plans to introduce expanded typing of any kind in the foreseeable future. And even if we did, I highly doubt it would happen before PHP 6. --Kris On Mon, Mar 5, 2012 at 6:20 PM, Raymond Irving xwis...@gmail.com wrote: Hello, I came across some info on the web that states that scalar type hinting was added to the PHP trunk but it did not make it's way into 5.4 because of objections from the community. Will it ever make it's way into 5.5? I know PHP is considered to be a weak typed language but it should also be about freedom. Freedom for a PHP developer to choose to use scalar type hinting whenever he/she sees the need. Best regards, __ Raymond
Re: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
Hi, Kris
I have to confirm that that's not really what I wanted.
But many people were now talking about type-hint to scalar, but that was
maybe in another thread in this list :)
To get more to the point what were discussing about want:
Why not always (at least try) to transform the data?
In PHP 5.4 they've introduced quite a lot of new stuff around exactly that:
* Changed silent conversion of array to string to produce a notice.
* Changed silent casting of null/''/false into an Object when adding a
property into a warning.
I would suppose to add a type-hint for the following types:
* Boolean
* integer
* float
* string
Here's the last state what I thought about these type-hints ...
Both of the given examples here should give the same result:
foo(boolean $b, integer $i, float $f, string $s) {
// your code
}
foo2($b, $i, $f, $s) {
$b = (boolean)$b;
$i = (integer)$i;
$f = (float)$f;
$s = (string)$s;
// your code
}
If you view it from that site - you can't get an array to do what you can
do with an object. Therefore I think it's quite OK to break the script
there, but here, as you can transform the values, I'd (at least try to)
transform the given data into the expected format.
The only thing I'm quite unsure about - should we trigger a E_WARNING or
E_NOTICE if we have data-loose in this transformation? Just let it pass as
it's transformable, but trigger some error ...
If you want to get a warning or notice in the function *foo2* then open a
new thread, as I think that should not be discussed here. It affects much
more than just the function-call.
p.s. What about adding another type-hint for resources?
That's something we could check by *is_resource()* and it would make sense
(at least to me).
Bye
Simon
2012/3/2 Kris Craig kris.cr...@gmail.com
I agree with what John said. Limiting the scope to scalars, while having
some advantages, probably wouldn't pass the usefulness test for most
people.
--Kris
On Thu, Mar 1, 2012 at 4:18 PM, John Crenshaw johncrens...@priacta.com
wrote:
From: Richard Lynch [mailto:c...@l-i-e.com]
On Thu, March 1, 2012 2:38 am, John Crenshaw wrote:
You might consider those scripts poor programming practice. We all
do.
But PHP is the language of the unwashed masses, and that was, and
is,
part of why it is hugely popular. Somebody who barely understands
programming can pound away at the keyboard and write a bloody useful
web application, breaking 10,000 Computer Science rules along the
way.
And in 20 minutes I can hack into that application 20 different ways.
This isn't really PHP's fault...or is it? By deliberately catering to
the lowest possible denominator is it possible that PHP itself
contributes to the proliferation of wildly insecure web sites? I do
understand the unwashed masses argument, and yet, the security geek
in me sometimes questions how good this is.
(Before someone flames me, I'm not really saying that we should scrap
any foundational principles or tell basic users to go hang
themselves.
This is mostly philosophical musing.)
We make concerted efforts to educate scripters, by posting the same
thing in all our blogs.
Even if all they understand is Don't do this! it's good enough for
most of them.
Other times the decision was made to just deprecate a feature and
provide a migration path,
if suitable, but spread out over major
releases:
PHP x.0: Feature is bad, but there
PHP x+1.0 Feature is E_DEPRECATED (or documented as such before E_DEP)
[This is the bit
where a LOT of scripted edumacation has to happen.) PHP x+2.0 Feature
is
just gone.
People who completely ignore docs or don't upgrade remain vulnerable,
but there's not much
you can do without making life miserable for a bazillion developers.
No, you've misunderstood. The average new not-really-a-developer has no
concept of security. Every SQL query they write is vulnerable to
injection.
Every echo exposes their site to XSS vulnerabilities. Every form is
vulnerable to CSRF. If they did anything with files in their script I may
be able to read arbitrary files to their server and/or upload and execute
arbitrary scripts. If they used eval() or system() I can probably execute
arbitrary shell code and take control of the entire site. If their server
is badly configured I could capture the entire machine.
This isn't a question of keeping software updated and not using
deprecated
functions, this is a question of discipline that is completely missing
among the unwashed masses as you call them. The intuitive way to handle
many of the most common PHP tasks is also the completely insecure way.
Philosophically, I wonder if we do a great disservice by encouraging
these
people to tinker with code at all. We do so knowing (or at least we
should
know) that anything they create will inevitably be hacked. We fuel the
widespread security
Re: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
Hi, All
Let me update my last functions as I got an inspiration from Anthony and
his proof-of-concept:
foo( (boolean) $b, (integer) $i, (float) $f, (string) $s) {
// your code
}
foo2($b, $i, $f, $s) {
$b = (boolean)$b;
$i = (integer)$i;
$f = (float)$f;
$s = (string)$s;
// your code
}
Now here a rule I thought could be acceptable to differ between the
type-hint for classes and arrays and this notation:
If the type is wrapped in parentheses, the system will try to convert the
given value. Otherwise it will handle it strict.
Strict is currently only available for classes and arrays, and I don't want
to get more things in this list (excepted by resources, what is the last
what would make sense here).
Dynamic (the one with the parentheses) could then well be something like
boolean, integer, float, string and array. Array is also in this list as I
would like to have an option to give an object in here that implements all
interfaces that makes an object accessible as an array - for example
ArrayIterator.
Bye
Simon
2012/3/2 Simon Schick simonsimc...@googlemail.com
Hi, Kris
I have to confirm that that's not really what I wanted.
But many people were now talking about type-hint to scalar, but that was
maybe in another thread in this list :)
To get more to the point what were discussing about want:
Why not always (at least try) to transform the data?
In PHP 5.4 they've introduced quite a lot of new stuff around exactly that:
* Changed silent conversion of array to string to produce a notice.
* Changed silent casting of null/''/false into an Object when adding a
property into a warning.
I would suppose to add a type-hint for the following types:
* Boolean
* integer
* float
* string
Here's the last state what I thought about these type-hints ...
Both of the given examples here should give the same result:
foo(boolean $b, integer $i, float $f, string $s) {
// your code
}
foo2($b, $i, $f, $s) {
$b = (boolean)$b;
$i = (integer)$i;
$f = (float)$f;
$s = (string)$s;
// your code
}
If you view it from that site - you can't get an array to do what you can
do with an object. Therefore I think it's quite OK to break the script
there, but here, as you can transform the values, I'd (at least try to)
transform the given data into the expected format.
The only thing I'm quite unsure about - should we trigger a E_WARNING or
E_NOTICE if we have data-loose in this transformation? Just let it pass as
it's transformable, but trigger some error ...
If you want to get a warning or notice in the function *foo2* then open a
new thread, as I think that should not be discussed here. It affects much
more than just the function-call.
p.s. What about adding another type-hint for resources?
That's something we could check by *is_resource()* and it would make
sense (at least to me).
Bye
Simon
2012/3/2 Kris Craig kris.cr...@gmail.com
I agree with what John said. Limiting the scope to scalars, while having
some advantages, probably wouldn't pass the usefulness test for most
people.
--Kris
On Thu, Mar 1, 2012 at 4:18 PM, John Crenshaw johncrens...@priacta.com
wrote:
From: Richard Lynch [mailto:c...@l-i-e.com]
On Thu, March 1, 2012 2:38 am, John Crenshaw wrote:
You might consider those scripts poor programming practice. We all
do.
But PHP is the language of the unwashed masses, and that was, and
is,
part of why it is hugely popular. Somebody who barely understands
programming can pound away at the keyboard and write a bloody
useful
web application, breaking 10,000 Computer Science rules along the
way.
And in 20 minutes I can hack into that application 20 different
ways.
This isn't really PHP's fault...or is it? By deliberately catering
to
the lowest possible denominator is it possible that PHP itself
contributes to the proliferation of wildly insecure web sites? I do
understand the unwashed masses argument, and yet, the security
geek
in me sometimes questions how good this is.
(Before someone flames me, I'm not really saying that we should
scrap
any foundational principles or tell basic users to go hang
themselves.
This is mostly philosophical musing.)
We make concerted efforts to educate scripters, by posting the same
thing in all our blogs.
Even if all they understand is Don't do this! it's good enough for
most of them.
Other times the decision was made to just deprecate a feature and
provide a migration path,
if suitable, but spread out over major
releases:
PHP x.0: Feature is bad, but there
PHP x+1.0 Feature is E_DEPRECATED (or documented as such before E_DEP)
[This is the bit
where a LOT of scripted edumacation has to happen.) PHP x+2.0 Feature
is
just gone.
People who completely ignore docs or don't upgrade remain vulnerable,
but there's not much
you can do without making life miserable for a bazillion
Re: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
On Thu, Mar 1, 2012 at 4:18 PM, John Crenshaw johncrens...@priacta.com wrote: No, you've misunderstood. The average new not-really-a-developer has no concept of security. Every SQL query they write is vulnerable to injection. Every echo exposes their site to XSS vulnerabilities. Every form is vulnerable to CSRF. If they did anything with files in their script I may be able to read arbitrary files to their server and/or upload and execute arbitrary scripts. If they used eval() or system() I can probably execute arbitrary shell code and take control of the entire site. If their server is badly configured I could capture the entire machine. PHP is as vulnerable as you make it, This isn't a question of keeping software updated and not using deprecated functions, this is a question of discipline that is completely missing among the unwashed masses as you call them. The intuitive way to handle many of the most common PHP tasks is also the completely insecure way. Philosophically, I wonder if we do a great disservice by encouraging these people to tinker with code at all. We do so knowing (or at least we should know) that anything they create will inevitably be hacked. We fuel the widespread security problems that currently plague the web. John Crenshaw Priacta, Inc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
You might consider those scripts poor programming practice. We all do. But PHP is the language of the unwashed masses, and that was, and is, part of why it is hugely popular. Somebody who barely understands programming can pound away at the keyboard and write a bloody useful web application, breaking 10,000 Computer Science rules along the way. And in 20 minutes I can hack into that application 20 different ways. This isn't really PHP's fault...or is it? By deliberately catering to the lowest possible denominator is it possible that PHP itself contributes to the proliferation of wildly insecure web sites? I do understand the unwashed masses argument, and yet, the security geek in me sometimes questions how good this is. (Before someone flames me, I'm not really saying that we should scrap any foundational principles or tell basic users to go hang themselves. This is mostly philosophical musing.) John Crenshaw Priacta, Inc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
Secure code is not about the instrument, it's about how you write it. Insecure spagetti code can be written in any language.
RE: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
From: Richard Lynch [mailto:c...@l-i-e.com]
On Wed, February 29, 2012 7:16 pm, John Crenshaw wrote:
I'm beginning to think that the type hinting question is too closely
related to the dirty secrets of type juggling to resolve them
separately. You may have to either discard consistency, or else fix
the problem of silent bizarre conversions at the same time ('foo'==0,
'123abc'=123). Fixing the conversions is a BC break though.
[short version]
One man's fixing is another man's feature :-)
Old hands can now hit delete while I wax philosophical.
The operative word was silent. The actual behavior is fine, but the silence
is unexpected. For example, PHP happily accepts substr('foo', 'bar') with no
complaint at all. From a purely philosophical perspective I think almost
everyone would expect *at least* a strict notice.
On a practical level, we have a major barrier and we'll have to decide how to
handle it. As I see it we could do one of the following:
1. Discard consistency (!!)
2. Try to convince people to make these bizarre conversions not silent (BC
break)
3. Try to find a creative solution to be consistent without changing anything
about the conversion behavior. (I'm not seeing a way to do this one, unless we
redefine consistent.)
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
Hi, John
Just to add an idea to yours ..
Do you think it's a compatibility-break if we'd decide to send a E_NOTICE
or E_WARNING if we f.e. try to give a string to a method that just allows
integer for this argument?
No break at all, just a E_NOTICE or E_WARNING as the script can succeed
anyways.
Bye
Simon
2012/3/1 John Crenshaw johncrens...@priacta.com
From: Richard Lynch [mailto:c...@l-i-e.com]
On Wed, February 29, 2012 7:16 pm, John Crenshaw wrote:
I'm beginning to think that the type hinting question is too closely
related to the dirty secrets of type juggling to resolve them
separately. You may have to either discard consistency, or else fix
the problem of silent bizarre conversions at the same time ('foo'==0,
'123abc'=123). Fixing the conversions is a BC break though.
[short version]
One man's fixing is another man's feature :-)
Old hands can now hit delete while I wax philosophical.
The operative word was silent. The actual behavior is fine, but the
silence is unexpected. For example, PHP happily accepts substr('foo',
'bar') with no complaint at all. From a purely philosophical perspective I
think almost everyone would expect *at least* a strict notice.
On a practical level, we have a major barrier and we'll have to decide how
to handle it. As I see it we could do one of the following:
1. Discard consistency (!!)
2. Try to convince people to make these bizarre conversions not silent (BC
break)
3. Try to find a creative solution to be consistent without changing
anything about the conversion behavior. (I'm not seeing a way to do this
one, unless we redefine consistent.)
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
From: Simon Schick [mailto:simonsimc...@googlemail.com] Hi, John Just to add an idea to yours .. Do you think it's a compatibility-break if we'd decide to send a E_NOTICE or E_WARNING if we f.e. try to give a string to a method that just allows integer for this argument? No break at all, just a E_NOTICE or E_WARNING as the script can succeed anyways. Bye Simon That's what I was calling inconsistent, specifically because (int)'foo' == 0 with no warning whatsoever, but int $a = 'foo' would be 0 with an error of some sort. Behavior with respect to when an error is raised is inconsistent. In both cases there is a very lossy conversion, why is there an error in one case and not the other? Inconsistent. On the other hand if you add an error in the legacy case now that's a BC break. One might argue that it should always have given a notice, but it didn't, so it's a change, and a BC break. Pick your poison. John Crenshaw Priacta, Inc.
Re: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
If any of you are interested in such change in PHP, please get
together and write a complete RFC. As I do not see any kind of
progress but, as you stated, some philosophical discussions. That's
all good but after 2 weeks, it is time to move forward (or stop).
Cheers,
On Thu, Mar 1, 2012 at 4:02 AM, Richard Lynch c...@l-i-e.com wrote:
On Wed, February 29, 2012 7:16 pm, John Crenshaw wrote:
I'm beginning to think that the type hinting question is too closely
related to the dirty secrets of type juggling to resolve them
separately. You may have to either discard consistency, or else fix
the problem of silent bizarre conversions at the same time ('foo'==0,
'123abc'=123). Fixing the conversions is a BC break though.
[short version]
One man's fixing is another man's feature :-)
Old hands can now hit delete while I wax philosophical.
[long version]
PHP does the type juggling because HTTP data is all string. It's a
feature, because PHP's main purpose was to process HTTP input.
[Yes, I know you did not dispute this. It's just foreshadowing...]
Once one accepts the premise that automatic type-juggling is good,
the idea that (int) 123 abc turns into 123 may seem incredibly
wrong or right depending on how useful one has found it.
I have found it useful, and others have as well, to the point that we
don't consider it something to fix but a feature
Obviously, others disagree. And that's okay. We get that some
disagree, and even why some disagree. We've all coded in C, C++, C#,
Forth, Modula 2, Lisp, PL/1, and many more, collectively.
We choose PHP, at times, because it is the way it is, as broken as
it may seem to others. And they are legion. One only needs to review
blogs and mailing lists of fans of other strictly-typed languages to
see this.
But Breaking Compatibility with something so deeply ingrained in the
culture and language, which goes back consistently at least to PHP3,
and probably PHP/FI, is a non-starter.
There are probably literally millions of scripts that will break out
there. That's simply unacceptable, and I trust you understand why
that is so.
You might consider those scripts poor programming practice. We all do.
But PHP is the language of the unwashed masses, and that was, and is,
part of why it is hugely popular. Somebody who barely understands
programming can pound away at the keyboard and write a bloody useful
web application, breaking 10,000 Computer Science rules along the way.
It's duct tape and bailing wire. And we love it for that.
If the app is useful enough, it might even get cleaned up. Or just
more duct tape and bailing wire is applied, more likely. :-)
Even at a major release, PHP has, by and large, strived to remain
Backwards Compatible, unless a VERY compelling reason was presented.
A vocal minority, or even a majority, of developers does not qualify.
That's pretty much why the Core Devs' veto power exists.
Some of the proposals and ideas lately have adhered to that concept of
not breaking Backwards Compatibility. Others have not, and those are
just non-starters.
But PHP core has always had the mantra Keep It Simple, Stupid
If one wants a complex language, PHP is simply not going to be it, and
virtually all of these proposals do not fit the KISS principle, at a
fundamental level of Any idiot can read halfway decent code and
puzzle out what it does in less than a day.
This is a Religious Issue, a personal preference, a philosophical
ideal, etc. Right or wrong, it is what it is, by choice, by the core
developers who have put years worth of effort into it.
Please don't read this as go away or a restatement of the arguments
that have been labeled as circular before. I am merely trying to
explain why PHP is the way it is, at a 10,000 foot level, and why so
many core devs are resistant to the changes being proposed.
I highly respect all the efforts and the alternative philosophical
differences, and even the guiding principles of Computer Science
driving them. PHP is just not the language for Computer Science types,
for the most part. It's for the masses.
Some CS types like it in certain situations, which is all to the good,
or it would be a total mess :-) We embrace its flaws and ugly hacks
because, like it or not, it works for what it's designed to do.
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
Kris Craig wrote: With all due respect, it's a logical fallacy to draw a direct comparison between these two simply because they both happen to be uphill battles. There is a direct comparison between the two. Both provide something that a large number of people did not or do not want anything to do with. Namespace was forced on us in much the same way you are currently trying to force this on us. Many people who were pursuaded that namespace was a good idea are now realising that it wasn't and was the thin end of wedge which this discussion is once again trying to force open. I have no objections to 'object orientated' as that is how I have always used PHP, but the BULK of the data I am handling is simply strings which 'magically' get converted to the format I need. I don't see any use for 'type hinting' in any form since I NEED to check if a string I get in has the right data in before I store it in a database field. I don't need to throw some random error which needs handling ... I just handle the errors in line as I process the data. My framework helps to ensure what I get in is right in the first place anyway, so even the in-line checks are probably redundant nowadays! -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
That's what I was calling inconsistent, specifically because (int)'foo' == 0 with no warning whatsoever, but int $a = 'foo' would be 0 with an error of some sort. Behavior with respect to when an error is raised is inconsistent. In both cases there is a very lossy conversion, why is there an error in one case and not the other? Inconsistent. +1 However, I would love to have int $a = 'foo' cast to 0 without any error. New functionality without breaking BC. Lazare INEPOLOGLOU Ingénieur Logiciel 2012/3/1 John Crenshaw johncrens...@priacta.com From: Simon Schick [mailto:simonsimc...@googlemail.com] Hi, John Just to add an idea to yours .. Do you think it's a compatibility-break if we'd decide to send a E_NOTICE or E_WARNING if we f.e. try to give a string to a method that just allows integer for this argument? No break at all, just a E_NOTICE or E_WARNING as the script can succeed anyways. Bye Simon That's what I was calling inconsistent, specifically because (int)'foo' == 0 with no warning whatsoever, but int $a = 'foo' would be 0 with an error of some sort. Behavior with respect to when an error is raised is inconsistent. In both cases there is a very lossy conversion, why is there an error in one case and not the other? Inconsistent. On the other hand if you add an error in the legacy case now that's a BC break. One might argue that it should always have given a notice, but it didn't, so it's a change, and a BC break. Pick your poison. John Crenshaw Priacta, Inc.
Re: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
On Thu, Mar 1, 2012 at 9:52 AM, Simon Schick simonsimc...@googlemail.comwrote:
Hi, John
Just to add an idea to yours ..
Do you think it's a compatibility-break if we'd decide to send a E_NOTICE
or E_WARNING if we f.e. try to give a string to a method that just allows
integer for this argument?
No break at all, just a E_NOTICE or E_WARNING as the script can succeed
anyways.
Perhaps I missed something, but since 5.3, the new parameter parsing API
throws a Warning when types are not strictly honored.
This has been a major feature in favor of cleaner programming.
Try substr('foo', 'bar'), in PHP = 5.3 and you get a warning and the
function returns null.
Julien.P
Bye
Simon
2012/3/1 John Crenshaw johncrens...@priacta.com
From: Richard Lynch [mailto:c...@l-i-e.com]
On Wed, February 29, 2012 7:16 pm, John Crenshaw wrote:
I'm beginning to think that the type hinting question is too closely
related to the dirty secrets of type juggling to resolve them
separately. You may have to either discard consistency, or else fix
the problem of silent bizarre conversions at the same time ('foo'==0,
'123abc'=123). Fixing the conversions is a BC break though.
[short version]
One man's fixing is another man's feature :-)
Old hands can now hit delete while I wax philosophical.
The operative word was silent. The actual behavior is fine, but the
silence is unexpected. For example, PHP happily accepts substr('foo',
'bar') with no complaint at all. From a purely philosophical perspective
I
think almost everyone would expect *at least* a strict notice.
On a practical level, we have a major barrier and we'll have to decide
how
to handle it. As I see it we could do one of the following:
1. Discard consistency (!!)
2. Try to convince people to make these bizarre conversions not silent
(BC
break)
3. Try to find a creative solution to be consistent without changing
anything about the conversion behavior. (I'm not seeing a way to do this
one, unless we redefine consistent.)
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
On Thu, Mar 1, 2012 at 9:00 AM, Lester Caine les...@lsces.co.uk wrote: Both provide something that a large number of people did not or do not want anything to do with. I disagree - The majority of PHP developers I've discussed this with are in favor of adding *something *like this. Do a majority want this? I have no idea and, I honestly don't believe you do either. Namespace was forced on us in much the same way you are currently trying to force this on us. Forced? Nobody is forcing anything. Discussions are happening, and possibly a vote in the future. This is the farthest thing from being forced IMO. Many people who were pursuaded that namespace was a good idea are now realising that it wasn't and was the thin end of wedge which this discussion is once again trying to force open. Many of the popular frameworks have made the changes, or are planning to make the changes, needed to take advantage of namespaces. This, to me, suggests a general acceptable of namespaces. Also - I'm yet to hear a single complaint about namespaces - although again, I've not talked to every PHP developer! (Well.. No complaints other than the namespace separator being a '\' that is) I have no objections to 'object orientated' as that is how I have always used PHP, but the BULK of the data I am handling is simply strings which 'magically' get converted to the format I need. I don't see any use for 'type hinting' in any form since I NEED to check if a string I get in has the right data in before I store it in a database field. I don't need to throw some random error which needs handling ... I just handle the errors in line as I process the data. My framework helps to ensure what I get in is right in the first place anyway, so even the in-line checks are probably redundant nowadays! I can certainly agree with you here - have I ever absolutely NEEDED this? Nope. Would it get it the way of writing code in certain situations? Yup. But - Does that mean it's not generally useful? Nope! Kiall
Re: [PHP-DEV] Scalar type hinting
Here's one thing to consider. Right now casting/type-autoconversion
is inconsistent at best. Let me show you what I mean:
If I add 1 to a variable, the variable is converted based on the
standard http://us2.php.net/manual/en/language.types.type-juggling.php
type juggling rules, but the variable is attempted to be converted to
a numeric type if it is not already one (based on the string
conversion to numbers rules:
http://us2.php.net/manual/en/language.types.string.php#language.types.string.conversion
)... I will refer to this as Numeric Type Juggling as we go on.
Note that objects cannot be used in this manner today, as they do not
implement the get() object handler, so they are converted to int(1) in
this context (which is defined as undefined by documentation). Also
note, that the string is cast to a number destructively. So if you do
1 + foo, you'll get 1 back without error or warning.
If I use a variable in a string context, the type juggling rules still
apply, but this time converting to a string if it is not already one.
This I think is the most straight forward (and sanest) of all the type
rules. I will refer to this as String Type Juggling as we go
forward. Note that object can be used in this context now, based on
the __toString method.
If I use a variable in a boolean context, the type juggling rules
still apply. So I can do if (array()), and the array will be
internally cast to a boolean to be evaluated. Let's call this
Boolean Type Juggling...
If I cast a variable to an array, it follows a standard conversion
policy which is documented here:
http://us2.php.net/manual/en/language.types.array.php#language.types.array.casting
I'll call this Array Type Juggling...
If I pass a variable to an internal function that expects a string
type, the String Type Juggling rules apply.
If I pass a variable to an internal function that expects a class, it
will convert the variable to a string, and then lookup the class to
see if it's valid. This is the same as String Type Juggling...
If I cast a variable to an object, it follows the documented casting
rules. Let's call this Object Type Juggling.
If I pass a variable to an external function that expects a class,
let's call this Object Hinted Type Juggling...
If I pass a variable to an internal function that expects a callback,
it will try to see if it's a valid callback by running logic if it's a
String, Array or Object. Other types are ignored and error out.
Let's call this Callback
That's where the sanity ends...
If I pass a variable to an internal function that expects an integer
or float, some weird things happen. If the argument is a float, it's
cast to an integer. If it's an integer, null, or boolean, it's
converted directly to an integer. But if it's an array, object or
resource, it causes an error. Up to now, it seems sane and right
inline with Numeric Type Juggling. Except that strings behave
differently. If the string is numeric (passes the is_numeric() test),
then the string will be cast to an integer and proceed as expected.
But if it is not, a warning is thrown and the internal function errors
out. This is quite different than Numeric Type Juggling, so I'll
call it Numeric Internal Parameter Type Juggling.
If I pass a variable to an internal function that expects a boolean,
it sort-of works. I can pass integers, strings, floats, and booleans,
and have normal type conversion rules apply. But if I pass in an
array, object or resource, then it will error out. So the type
juggling rules work for primitives, but not for complex types, which
is different from Boolean Type Juggling, so we'll call it Boolean
Internal Parameter Type Juggling.
If I pass a variable to an internal function that expects an array, it
will error out if not. It will not even attempt a cast, which is
quite different from Array Type Juggling. So let's call this Array
Internal Parameter Type Juggling (even though it doesn't juggle
anything)...
If I pass a variable to an internal function that expects a hash table
it can conditionally accept an object (as long as the hash table param
is defined as a capital H). This is even more different than arrays,
so Hash Table Internal Parameter Type Jugging...
If I pass a variable to an internal function that expects an object,
it will error if it's not an object with no casting attempt. Let's
call this Object Internal Parameter Type Juggling.
So in reality, there are tons of different rules and cases on how this
happens.
But the odd thing is that while we can wrap internal functions, we
cannot use the same casting rules as they can. So writing a wrapper
for substr is non-trivial. You **HAVE** to:
function mysubstr($string, $from, $to = 0) {
if (!is_numeric($from)) {
throw new Exception('From Must Be Numeric');
}
if (!is_numeric($to)) {
throw new Exception('To Must Be Numeric');
}
return substr($string, $from, $to);
}
Otherwise your code will possibly throw errors.
RE: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
From: Richard Lynch [mailto:c...@l-i-e.com]
On Wed, February 29, 2012 7:16 pm, John Crenshaw wrote:
I'm beginning to think that the type hinting question is too closely
related to the dirty secrets of type juggling to resolve them
separately. You may have to either discard consistency, or else fix
the problem of silent bizarre conversions at the same time ('foo'==0,
'123abc'=123). Fixing the conversions is a BC break though.
[short version]
One man's fixing is another man's feature :-)
Old hands can now hit delete while I wax philosophical.
The operative word was silent. The actual behavior is fine, but the
silence is unexpected. For example, PHP happily accepts substr('foo',
'bar') with no complaint at all. From a purely philosophical perspective I
think almost everyone would expect *at least* a strict notice.
On a practical level, we have a major barrier and we'll have to decide how
to handle it. As I see it we could do one of the following:
1. Discard consistency (!!)
2. Try to convince people to make these bizarre conversions not silent (BC
break)
3. Try to find a creative solution to be consistent without changing
anything about the conversion behavior. (I'm not seeing a way to do this
one, unless we redefine consistent.)
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Thu, Mar 1, 2012 at 9:52 AM, Simon Schick simonsimc...@googlemail.com
wrote:
Hi, John
Just to add an idea to yours ..
Do you think it's a compatibility-break if we'd decide to send a E_NOTICE
or E_WARNING if we f.e. try to give a string to a method that just allows
integer for this argument?
No break at all, just a E_NOTICE or E_WARNING as the script can succeed
anyways.
Perhaps I missed something, but since 5.3, the new parameter parsing API
throws a Warning when types are not strictly honored.
This has been a major feature in favor of cleaner programming.
Try substr('foo', 'bar'), in PHP = 5.3 and you get a warning and the
function returns null.
Julien.P
Bye
Simon
Ah, didn't notice the *new* behavior. That simplifies things substantially.
I also had another realization today, which is that there's already strong
precedent for treating parameter hints more aggressively than a type cast. For
example, you can cast between arrays and objects, with no errors, but the type
hints will still generate errors. I think this settles the consistency issue
for me.
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
@Lester Well there's another logical fallacy. How, exactly, am I trying to force this on anyone? Last time I checked, the PHP community has a voting process that requires a 2/3 majority for anything touching the code. Also, last time I checked, there are numerous people who do want this, so I would definitely dispute some of the claims that this is dead in the water so-to-speak. This has nothing whatsoever to do with implementing namespaces. That's a non-sequitur. Drawing a comparison because they both happen to be controversial ideas would be like me comparing you to Joseph Stalin because you both happen to breathe oxygen. The fact alone that something is controversial does not automatically mean it's a bad idea. Likewise, the fact that namespaces turned out to have unanticipated results does not mean that the same will happen with this. --Kris On Thu, Mar 1, 2012 at 10:06 AM, Anthony Ferrara ircmax...@gmail.comwrote: Here's one thing to consider. Right now casting/type-autoconversion is inconsistent at best. Let me show you what I mean: If I add 1 to a variable, the variable is converted based on the standard http://us2.php.net/manual/en/language.types.type-juggling.php type juggling rules, but the variable is attempted to be converted to a numeric type if it is not already one (based on the string conversion to numbers rules: http://us2.php.net/manual/en/language.types.string.php#language.types.string.conversion )... I will refer to this as Numeric Type Juggling as we go on. Note that objects cannot be used in this manner today, as they do not implement the get() object handler, so they are converted to int(1) in this context (which is defined as undefined by documentation). Also note, that the string is cast to a number destructively. So if you do 1 + foo, you'll get 1 back without error or warning. If I use a variable in a string context, the type juggling rules still apply, but this time converting to a string if it is not already one. This I think is the most straight forward (and sanest) of all the type rules. I will refer to this as String Type Juggling as we go forward. Note that object can be used in this context now, based on the __toString method. If I use a variable in a boolean context, the type juggling rules still apply. So I can do if (array()), and the array will be internally cast to a boolean to be evaluated. Let's call this Boolean Type Juggling... If I cast a variable to an array, it follows a standard conversion policy which is documented here: http://us2.php.net/manual/en/language.types.array.php#language.types.array.casting I'll call this Array Type Juggling... If I pass a variable to an internal function that expects a string type, the String Type Juggling rules apply. If I pass a variable to an internal function that expects a class, it will convert the variable to a string, and then lookup the class to see if it's valid. This is the same as String Type Juggling... If I cast a variable to an object, it follows the documented casting rules. Let's call this Object Type Juggling. If I pass a variable to an external function that expects a class, let's call this Object Hinted Type Juggling... If I pass a variable to an internal function that expects a callback, it will try to see if it's a valid callback by running logic if it's a String, Array or Object. Other types are ignored and error out. Let's call this Callback That's where the sanity ends... If I pass a variable to an internal function that expects an integer or float, some weird things happen. If the argument is a float, it's cast to an integer. If it's an integer, null, or boolean, it's converted directly to an integer. But if it's an array, object or resource, it causes an error. Up to now, it seems sane and right inline with Numeric Type Juggling. Except that strings behave differently. If the string is numeric (passes the is_numeric() test), then the string will be cast to an integer and proceed as expected. But if it is not, a warning is thrown and the internal function errors out. This is quite different than Numeric Type Juggling, so I'll call it Numeric Internal Parameter Type Juggling. If I pass a variable to an internal function that expects a boolean, it sort-of works. I can pass integers, strings, floats, and booleans, and have normal type conversion rules apply. But if I pass in an array, object or resource, then it will error out. So the type juggling rules work for primitives, but not for complex types, which is different from Boolean Type Juggling, so we'll call it Boolean Internal Parameter Type Juggling. If I pass a variable to an internal function that expects an array, it will error out if not. It will not even attempt a cast, which is quite different from Array Type Juggling. So let's call this Array Internal Parameter Type Juggling (even though it doesn't juggle anything)... If I pass a
Re: [PHP-DEV] Scalar type hinting
On Thu, 01 Mar 2012 20:51:17 +0100, Kris Craig kris.cr...@gmail.com wrote: @Lester Well there's another logical fallacy. How, exactly, am I trying to force this on anyone? Last time I checked, the PHP community has a voting process that requires a 2/3 majority for anything touching the code. Also, last time I checked, there are numerous people who do want this, so I would definitely dispute some of the claims that this is dead in the water so-to-speak. [...] Seeing the same issues relitigated all over again in absurdly long threads is annoying, but seeing these meta-discussions is exasperating (I've lost the count of the number of e-mails just speculating about the likelihood of success of such a proposal). So please, by all means come up with an actual proposal (implementation included) and take it to a vote, but stop these meta-discussions and avoid recycling arguments just so you can have the last word. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
On Thu, March 1, 2012 2:38 am, John Crenshaw wrote: You might consider those scripts poor programming practice. We all do. But PHP is the language of the unwashed masses, and that was, and is, part of why it is hugely popular. Somebody who barely understands programming can pound away at the keyboard and write a bloody useful web application, breaking 10,000 Computer Science rules along the way. And in 20 minutes I can hack into that application 20 different ways. This isn't really PHP's fault...or is it? By deliberately catering to the lowest possible denominator is it possible that PHP itself contributes to the proliferation of wildly insecure web sites? I do understand the unwashed masses argument, and yet, the security geek in me sometimes questions how good this is. (Before someone flames me, I'm not really saying that we should scrap any foundational principles or tell basic users to go hang themselves. This is mostly philosophical musing.) We make concerted efforts to educate scripters, by posting the same thing in all our blogs. Even if all they understand is Don't do this! it's good enough for most of them. Other times the decision was made to just deprecate a feature and provide a migration path, if suitable, but spread out over major releases: PHP x.0: Feature is bad, but there PHP x+1.0 Feature is E_DEPRECATED (or documented as such before E_DEP) [This is the bit where a LOT of scripted edumacation has to happen.) PHP x+2.0 Feature is just gone. People who completely ignore docs or don't upgrade remain vulnerable, but there's not much you can do without making life miserable for a bazillion developers. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
Hi, John
Therefore I think it would be easy to explain how a type-hint for scalar
could work.
You can explain it as saying that the following two functions should be end
up in exactly the same result, whatever you're pasting into:
function foo_one(scalar $bar) {}
function foo_two($bar) {
if (!is_scalar($bar))
trigger_error(Catchable fatal error: Argument ? passed to ? must be a
scalar, ? given,, E_RECOVERABLE_ERROR);
}
The error-message is just an example - but that would keep the three
type-hint possibilities in one and the same functionality - like just
allowing exactly this type.
You cannot even pass a class that extends* ArrayIterator *into a property
that requires an array. So I think we should also here (at least for
scalar) do a really strict thing.
Bye
Simon
2012/3/1 John Crenshaw johncrens...@priacta.com
From: Richard Lynch [mailto:c...@l-i-e.com]
On Wed, February 29, 2012 7:16 pm, John Crenshaw wrote:
I'm beginning to think that the type hinting question is too
closely
related to the dirty secrets of type juggling to resolve them
separately. You may have to either discard consistency, or else fix
the problem of silent bizarre conversions at the same time
('foo'==0,
'123abc'=123). Fixing the conversions is a BC break though.
[short version]
One man's fixing is another man's feature :-)
Old hands can now hit delete while I wax philosophical.
The operative word was silent. The actual behavior is fine, but the
silence is unexpected. For example, PHP happily accepts substr('foo',
'bar') with no complaint at all. From a purely philosophical
perspective I
think almost everyone would expect *at least* a strict notice.
On a practical level, we have a major barrier and we'll have to decide
how
to handle it. As I see it we could do one of the following:
1. Discard consistency (!!)
2. Try to convince people to make these bizarre conversions not silent
(BC
break)
3. Try to find a creative solution to be consistent without changing
anything about the conversion behavior. (I'm not seeing a way to do
this
one, unless we redefine consistent.)
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Thu, Mar 1, 2012 at 9:52 AM, Simon Schick
simonsimc...@googlemail.com wrote:
Hi, John
Just to add an idea to yours ..
Do you think it's a compatibility-break if we'd decide to send a E_NOTICE
or E_WARNING if we f.e. try to give a string to a method that just allows
integer for this argument?
No break at all, just a E_NOTICE or E_WARNING as the script can succeed
anyways.
Perhaps I missed something, but since 5.3, the new parameter parsing API
throws a Warning when types are not strictly honored.
This has been a major feature in favor of cleaner programming.
Try substr('foo', 'bar'), in PHP = 5.3 and you get a warning and the
function returns null.
Julien.P
Bye
Simon
Ah, didn't notice the *new* behavior. That simplifies things substantially.
I also had another realization today, which is that there's already strong
precedent for treating parameter hints more aggressively than a type cast.
For example, you can cast between arrays and objects, with no errors, but
the type hints will still generate errors. I think this settles the
consistency issue for me.
John Crenshaw
Priacta, Inc.
RE: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
From: Simon Schick [mailto:simonsimc...@googlemail.com]
Hi, John
Therefore I think it would be easy to explain how a type-hint for scalar
could work.
You can explain it as saying that the following two functions should be end
up in exactly the same result, whatever you're pasting into:
function foo_one(scalar $bar) {}
function foo_two($bar) {
if (!is_scalar($bar))
trigger_error(Catchable fatal error: Argument ? passed to ? must be a
scalar, ? given,, E_RECOVERABLE_ERROR);
}
Type hints that only ensure that something is a scalar are a non-starter for
me. I'm not going to waste my time on something like that. You're not going to
get any better core support with this, and you'll alienate support from a
majority of userland as well. The average function doesn't need just a scalar,
but any scalar will do. Most functions need something specific, like a string,
or a number. sqrt('foo') doesn't make any sense, it needs a number, not just a
scalar.
John Crenshaw
Priacta, Inc.
RE: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
From: Richard Lynch [mailto:c...@l-i-e.com] On Thu, March 1, 2012 2:38 am, John Crenshaw wrote: You might consider those scripts poor programming practice. We all do. But PHP is the language of the unwashed masses, and that was, and is, part of why it is hugely popular. Somebody who barely understands programming can pound away at the keyboard and write a bloody useful web application, breaking 10,000 Computer Science rules along the way. And in 20 minutes I can hack into that application 20 different ways. This isn't really PHP's fault...or is it? By deliberately catering to the lowest possible denominator is it possible that PHP itself contributes to the proliferation of wildly insecure web sites? I do understand the unwashed masses argument, and yet, the security geek in me sometimes questions how good this is. (Before someone flames me, I'm not really saying that we should scrap any foundational principles or tell basic users to go hang themselves. This is mostly philosophical musing.) We make concerted efforts to educate scripters, by posting the same thing in all our blogs. Even if all they understand is Don't do this! it's good enough for most of them. Other times the decision was made to just deprecate a feature and provide a migration path, if suitable, but spread out over major releases: PHP x.0: Feature is bad, but there PHP x+1.0 Feature is E_DEPRECATED (or documented as such before E_DEP) [This is the bit where a LOT of scripted edumacation has to happen.) PHP x+2.0 Feature is just gone. People who completely ignore docs or don't upgrade remain vulnerable, but there's not much you can do without making life miserable for a bazillion developers. No, you've misunderstood. The average new not-really-a-developer has no concept of security. Every SQL query they write is vulnerable to injection. Every echo exposes their site to XSS vulnerabilities. Every form is vulnerable to CSRF. If they did anything with files in their script I may be able to read arbitrary files to their server and/or upload and execute arbitrary scripts. If they used eval() or system() I can probably execute arbitrary shell code and take control of the entire site. If their server is badly configured I could capture the entire machine. This isn't a question of keeping software updated and not using deprecated functions, this is a question of discipline that is completely missing among the unwashed masses as you call them. The intuitive way to handle many of the most common PHP tasks is also the completely insecure way. Philosophically, I wonder if we do a great disservice by encouraging these people to tinker with code at all. We do so knowing (or at least we should know) that anything they create will inevitably be hacked. We fuel the widespread security problems that currently plague the web. John Crenshaw Priacta, Inc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
I agree with what John said. Limiting the scope to scalars, while having some advantages, probably wouldn't pass the usefulness test for most people. --Kris On Thu, Mar 1, 2012 at 4:18 PM, John Crenshaw johncrens...@priacta.comwrote: From: Richard Lynch [mailto:c...@l-i-e.com] On Thu, March 1, 2012 2:38 am, John Crenshaw wrote: You might consider those scripts poor programming practice. We all do. But PHP is the language of the unwashed masses, and that was, and is, part of why it is hugely popular. Somebody who barely understands programming can pound away at the keyboard and write a bloody useful web application, breaking 10,000 Computer Science rules along the way. And in 20 minutes I can hack into that application 20 different ways. This isn't really PHP's fault...or is it? By deliberately catering to the lowest possible denominator is it possible that PHP itself contributes to the proliferation of wildly insecure web sites? I do understand the unwashed masses argument, and yet, the security geek in me sometimes questions how good this is. (Before someone flames me, I'm not really saying that we should scrap any foundational principles or tell basic users to go hang themselves. This is mostly philosophical musing.) We make concerted efforts to educate scripters, by posting the same thing in all our blogs. Even if all they understand is Don't do this! it's good enough for most of them. Other times the decision was made to just deprecate a feature and provide a migration path, if suitable, but spread out over major releases: PHP x.0: Feature is bad, but there PHP x+1.0 Feature is E_DEPRECATED (or documented as such before E_DEP) [This is the bit where a LOT of scripted edumacation has to happen.) PHP x+2.0 Feature is just gone. People who completely ignore docs or don't upgrade remain vulnerable, but there's not much you can do without making life miserable for a bazillion developers. No, you've misunderstood. The average new not-really-a-developer has no concept of security. Every SQL query they write is vulnerable to injection. Every echo exposes their site to XSS vulnerabilities. Every form is vulnerable to CSRF. If they did anything with files in their script I may be able to read arbitrary files to their server and/or upload and execute arbitrary scripts. If they used eval() or system() I can probably execute arbitrary shell code and take control of the entire site. If their server is badly configured I could capture the entire machine. This isn't a question of keeping software updated and not using deprecated functions, this is a question of discipline that is completely missing among the unwashed masses as you call them. The intuitive way to handle many of the most common PHP tasks is also the completely insecure way. Philosophically, I wonder if we do a great disservice by encouraging these people to tinker with code at all. We do so knowing (or at least we should know) that anything they create will inevitably be hacked. We fuel the widespread security problems that currently plague the web. John Crenshaw Priacta, Inc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
Hi, John
I personally do not care about weak or strong variables at all ... I only
want what Arvids suggested last time:
test(1, 2); // 2;
test(1, 2); // 2
test(1aaa, 2); // E_NOTICE or E_TYPE and result 2
test(array(2), 2); // E_RECOVERABLE_ERROR - just like with array type
hint now.
It's really what the most people want. Simple, easy to pick up (object
and array already have this) and is just optional.
I count myself as a part of *most people* in this statement ;)
I'm also quite fine with the current type-hints as you'd anyways get an
error if you try something like this:
function foo(SimpleClass $a) {
$a-getName();
}
foo(Test);
If you now get *method called from an non-object* or a message that you
have passed a value that's not compatible with *SimpleClass* ...
I'd like to split this discussion in parts:
- just type-hint in functions (as we have it with classes and arrays) or
bind a variable to a strict type?
- should it then also be possible bind variables to a specific class
or interface?
- should we go for weak or strong types?
- the type-hint is also weak in one way because it accepts all that's
compatible with the given type.
Bye
Simon
2012/2/29 John Crenshaw johncrens...@priacta.com
I would personally be inclined towards something simpler like E_NOTICE or
E_WARNING, but current type hints all raise E_RECOVERABLE_ERROR. I think we
should be consistent, and the consistency argument may make the difference.
There may be a strong case for changing the error level on all type hints
to something simpler (or new, like E_TYPE), but I think that might be
better to tackle that in a separate discussion.
John Crenshaw
Priacta, Inc.
From: Kris Craig [mailto:kris.cr...@gmail.com]
Sent: Tuesday, February 28, 2012 8:40 PM
To: John Crenshaw
Cc: Rick WIdmer; internals@lists.php.net
Subject: Re: [PHP-DEV] Scalar type hinting
I wouldn't mind that, though I'm concerned that it may not be sellable
because some people on here have expressed a strong opinion that this
shouldn't throw anything more than a notice or a warning at most, something
that I and others strongly disagree with. The logical approach, to me at
least, is to follow the example of include() and require(); i.e. they're
both identical except that one throws a scary error while the other one is
just a warning.
I'm fine with just throwing E_RECOVERABLE_ERROR, though I fear that may
alienate too many people for us to be able to get this through. Though
it's possible I might be overestimating that factor.
--Kris
On Tue, Feb 28, 2012 at 5:17 PM, John Crenshaw johncrens...@priacta.com
mailto:johncrens...@priacta.com wrote:
On Tue, Feb 28, 2012 at 3:03 PM, Rick WIdmer vch...@developersdesk.com
mailto:vch...@developersdesk.comwrote:
On 2/28/2012 2:58 PM, Kris Craig wrote:
strong int $a = 1; // Converts to 1. May or may not throw an error
(I'm
still on the fence).
It this is an error, it is no longer PHP.
@Rick Though I'm not sure I'd agree with the overly broad it is no
longer PHP hyperbole, I think the basic point that it would be a
significant departure from the current model has merit. So ok, you've
convinced me.
That example should not throw any errors. I'm officially no longer on the
fence with that. =)
--Kris
OK, if we're all on the same page there, I think this means that there is
no significant difference between the strong int and weak int in your
proposal (the only remaining difference being the level of error raised
when it cannot be converted, which IMO is not substantial enough to deserve
a keyword.) I'd prefer to just pick one error level to use
(E_RECOVERABLE_ERROR would be the most consistent) and keep everything
simple.
John Crenshaw
Priacta, Inc.
Re: [PHP-DEV] Scalar type hinting
Hi,
We could even combine this with the following RFC:
https://wiki.php.net/rfc/object_cast_magic
If an integer is required and you pass an object, it first checks if this
object is castable to integer ;)
Bye
Simon
2012/2/29 Simon Schick simonsimc...@googlemail.com
Hi, John
I personally do not care about weak or strong variables at all ... I only
want what Arvids suggested last time:
test(1, 2); // 2;
test(1, 2); // 2
test(1aaa, 2); // E_NOTICE or E_TYPE and result 2
test(array(2), 2); // E_RECOVERABLE_ERROR - just like with array type
hint now.
It's really what the most people want. Simple, easy to pick up (object
and array already have this) and is just optional.
I count myself as a part of *most people* in this statement ;)
I'm also quite fine with the current type-hints as you'd anyways get an
error if you try something like this:
function foo(SimpleClass $a) {
$a-getName();
}
foo(Test);
If you now get *method called from an non-object* or a message that you
have passed a value that's not compatible with *SimpleClass* ...
I'd like to split this discussion in parts:
- just type-hint in functions (as we have it with classes and arrays)
or bind a variable to a strict type?
- should it then also be possible bind variables to a specific
class or interface?
- should we go for weak or strong types?
- the type-hint is also weak in one way because it accepts all
that's compatible with the given type.
Bye
Simon
2012/2/29 John Crenshaw johncrens...@priacta.com
I would personally be inclined towards something simpler like E_NOTICE or
E_WARNING, but current type hints all raise E_RECOVERABLE_ERROR. I think we
should be consistent, and the consistency argument may make the difference.
There may be a strong case for changing the error level on all type hints
to something simpler (or new, like E_TYPE), but I think that might be
better to tackle that in a separate discussion.
John Crenshaw
Priacta, Inc.
From: Kris Craig [mailto:kris.cr...@gmail.com]
Sent: Tuesday, February 28, 2012 8:40 PM
To: John Crenshaw
Cc: Rick WIdmer; internals@lists.php.net
Subject: Re: [PHP-DEV] Scalar type hinting
I wouldn't mind that, though I'm concerned that it may not be sellable
because some people on here have expressed a strong opinion that this
shouldn't throw anything more than a notice or a warning at most, something
that I and others strongly disagree with. The logical approach, to me at
least, is to follow the example of include() and require(); i.e. they're
both identical except that one throws a scary error while the other one is
just a warning.
I'm fine with just throwing E_RECOVERABLE_ERROR, though I fear that may
alienate too many people for us to be able to get this through. Though
it's possible I might be overestimating that factor.
--Kris
On Tue, Feb 28, 2012 at 5:17 PM, John Crenshaw johncrens...@priacta.com
mailto:johncrens...@priacta.com wrote:
On Tue, Feb 28, 2012 at 3:03 PM, Rick WIdmer vch...@developersdesk.com
mailto:vch...@developersdesk.comwrote:
On 2/28/2012 2:58 PM, Kris Craig wrote:
strong int $a = 1; // Converts to 1. May or may not throw an error
(I'm
still on the fence).
It this is an error, it is no longer PHP.
@Rick Though I'm not sure I'd agree with the overly broad it is no
longer PHP hyperbole, I think the basic point that it would be a
significant departure from the current model has merit. So ok, you've
convinced me.
That example should not throw any errors. I'm officially no longer on
the fence with that. =)
--Kris
OK, if we're all on the same page there, I think this means that there is
no significant difference between the strong int and weak int in your
proposal (the only remaining difference being the level of error raised
when it cannot be converted, which IMO is not substantial enough to deserve
a keyword.) I'd prefer to just pick one error level to use
(E_RECOVERABLE_ERROR would be the most consistent) and keep everything
simple.
John Crenshaw
Priacta, Inc.
Re: [PHP-DEV] Scalar type hinting
Combining different things into one big RFC is not a good idea. It's
hard to develop and test the work it it's in one big chunk.
Decomposition makes it much easier. Type hinting has to have it's own
RFC.
Besides - someone can be willing to do type hinting patch and don't
want to do the object_cast_magic one.
And thanks for the support :)
2012/2/29 Simon Schick simonsimc...@googlemail.com:
Hi,
We could even combine this with the following RFC:
https://wiki.php.net/rfc/object_cast_magic
If an integer is required and you pass an object, it first checks if this
object is castable to integer ;)
Bye
Simon
2012/2/29 Simon Schick simonsimc...@googlemail.com
Hi, John
I personally do not care about weak or strong variables at all ... I only
want what Arvids suggested last time:
test(1, 2); // 2;
test(1, 2); // 2
test(1aaa, 2); // E_NOTICE or E_TYPE and result 2
test(array(2), 2); // E_RECOVERABLE_ERROR - just like with array type
hint now.
It's really what the most people want. Simple, easy to pick up (object
and array already have this) and is just optional.
I count myself as a part of *most people* in this statement ;)
I'm also quite fine with the current type-hints as you'd anyways get an
error if you try something like this:
function foo(SimpleClass $a) {
$a-getName();
}
foo(Test);
If you now get *method called from an non-object* or a message that you
have passed a value that's not compatible with *SimpleClass* ...
I'd like to split this discussion in parts:
- just type-hint in functions (as we have it with classes and arrays)
or bind a variable to a strict type?
- should it then also be possible bind variables to a specific
class or interface?
- should we go for weak or strong types?
- the type-hint is also weak in one way because it accepts all
that's compatible with the given type.
Bye
Simon
2012/2/29 John Crenshaw johncrens...@priacta.com
I would personally be inclined towards something simpler like E_NOTICE or
E_WARNING, but current type hints all raise E_RECOVERABLE_ERROR. I think we
should be consistent, and the consistency argument may make the difference.
There may be a strong case for changing the error level on all type hints
to something simpler (or new, like E_TYPE), but I think that might be
better to tackle that in a separate discussion.
John Crenshaw
Priacta, Inc.
From: Kris Craig [mailto:kris.cr...@gmail.com]
Sent: Tuesday, February 28, 2012 8:40 PM
To: John Crenshaw
Cc: Rick WIdmer; internals@lists.php.net
Subject: Re: [PHP-DEV] Scalar type hinting
I wouldn't mind that, though I'm concerned that it may not be sellable
because some people on here have expressed a strong opinion that this
shouldn't throw anything more than a notice or a warning at most, something
that I and others strongly disagree with. The logical approach, to me at
least, is to follow the example of include() and require(); i.e. they're
both identical except that one throws a scary error while the other one is
just a warning.
I'm fine with just throwing E_RECOVERABLE_ERROR, though I fear that may
alienate too many people for us to be able to get this through. Though
it's possible I might be overestimating that factor.
--Kris
On Tue, Feb 28, 2012 at 5:17 PM, John Crenshaw johncrens...@priacta.com
mailto:johncrens...@priacta.com wrote:
On Tue, Feb 28, 2012 at 3:03 PM, Rick WIdmer vch...@developersdesk.com
mailto:vch...@developersdesk.comwrote:
On 2/28/2012 2:58 PM, Kris Craig wrote:
strong int $a = 1; // Converts to 1. May or may not throw an error
(I'm
still on the fence).
It this is an error, it is no longer PHP.
@Rick Though I'm not sure I'd agree with the overly broad it is no
longer PHP hyperbole, I think the basic point that it would be a
significant departure from the current model has merit. So ok, you've
convinced me.
That example should not throw any errors. I'm officially no longer on
the fence with that. =)
--Kris
OK, if we're all on the same page there, I think this means that there is
no significant difference between the strong int and weak int in your
proposal (the only remaining difference being the level of error raised
when it cannot be converted, which IMO is not substantial enough to deserve
a keyword.) I'd prefer to just pick one error level to use
(E_RECOVERABLE_ERROR would be the most consistent) and keep everything
simple.
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
Hi, Arvids
I did not meant to putt all in one big RFC but more to think about the
connection between these two while developing.
Bye
Simon
2012/2/29 Arvids Godjuks arvids.godj...@gmail.com
Combining different things into one big RFC is not a good idea. It's
hard to develop and test the work it it's in one big chunk.
Decomposition makes it much easier. Type hinting has to have it's own
RFC.
Besides - someone can be willing to do type hinting patch and don't
want to do the object_cast_magic one.
And thanks for the support :)
2012/2/29 Simon Schick simonsimc...@googlemail.com:
Hi,
We could even combine this with the following RFC:
https://wiki.php.net/rfc/object_cast_magic
If an integer is required and you pass an object, it first checks if this
object is castable to integer ;)
Bye
Simon
2012/2/29 Simon Schick simonsimc...@googlemail.com
Hi, John
I personally do not care about weak or strong variables at all ... I
only
want what Arvids suggested last time:
test(1, 2); // 2;
test(1, 2); // 2
test(1aaa, 2); // E_NOTICE or E_TYPE and result 2
test(array(2), 2); // E_RECOVERABLE_ERROR - just like with array type
hint now.
It's really what the most people want. Simple, easy to pick up (object
and array already have this) and is just optional.
I count myself as a part of *most people* in this statement ;)
I'm also quite fine with the current type-hints as you'd anyways get an
error if you try something like this:
function foo(SimpleClass $a) {
$a-getName();
}
foo(Test);
If you now get *method called from an non-object* or a message that you
have passed a value that's not compatible with *SimpleClass* ...
I'd like to split this discussion in parts:
- just type-hint in functions (as we have it with classes and arrays)
or bind a variable to a strict type?
- should it then also be possible bind variables to a specific
class or interface?
- should we go for weak or strong types?
- the type-hint is also weak in one way because it accepts all
that's compatible with the given type.
Bye
Simon
2012/2/29 John Crenshaw johncrens...@priacta.com
I would personally be inclined towards something simpler like E_NOTICE
or
E_WARNING, but current type hints all raise E_RECOVERABLE_ERROR. I
think we
should be consistent, and the consistency argument may make the
difference.
There may be a strong case for changing the error level on all type
hints
to something simpler (or new, like E_TYPE), but I think that might be
better to tackle that in a separate discussion.
John Crenshaw
Priacta, Inc.
From: Kris Craig [mailto:kris.cr...@gmail.com]
Sent: Tuesday, February 28, 2012 8:40 PM
To: John Crenshaw
Cc: Rick WIdmer; internals@lists.php.net
Subject: Re: [PHP-DEV] Scalar type hinting
I wouldn't mind that, though I'm concerned that it may not be sellable
because some people on here have expressed a strong opinion that this
shouldn't throw anything more than a notice or a warning at most,
something
that I and others strongly disagree with. The logical approach, to me
at
least, is to follow the example of include() and require(); i.e.
they're
both identical except that one throws a scary error while the other
one is
just a warning.
I'm fine with just throwing E_RECOVERABLE_ERROR, though I fear that may
alienate too many people for us to be able to get this through. Though
it's possible I might be overestimating that factor.
--Kris
On Tue, Feb 28, 2012 at 5:17 PM, John Crenshaw
johncrens...@priacta.com
mailto:johncrens...@priacta.com wrote:
On Tue, Feb 28, 2012 at 3:03 PM, Rick WIdmer
vch...@developersdesk.com
mailto:vch...@developersdesk.comwrote:
On 2/28/2012 2:58 PM, Kris Craig wrote:
strong int $a = 1; // Converts to 1. May or may not throw an
error
(I'm
still on the fence).
It this is an error, it is no longer PHP.
@Rick Though I'm not sure I'd agree with the overly broad it is no
longer PHP hyperbole, I think the basic point that it would be a
significant departure from the current model has merit. So ok, you've
convinced me.
That example should not throw any errors. I'm officially no longer on
the fence with that. =)
--Kris
OK, if we're all on the same page there, I think this means that there
is
no significant difference between the strong int and weak int in
your
proposal (the only remaining difference being the level of error raised
when it cannot be converted, which IMO is not substantial enough to
deserve
a keyword.) I'd prefer to just pick one error level to use
(E_RECOVERABLE_ERROR would be the most consistent) and keep everything
simple.
John Crenshaw
Priacta, Inc.
Re: [PHP-DEV] Scalar type hinting
int $a = 1; // no error. 1 == 1 so who cares? int $a = 'House'; // error 0 != 'House', so this is a problem. For the sake of consistency, please take into account this example, which works in the current implementation of PHP: $b = 1 + 1; // no error, $b == 2 $b = 1 + House; // no error, $b == 1 So, I believe that, raising an error or not, is not a question of the new RFC. Should there be an error, then it has to be in every unsuccessful type juggling, regardless of the final assignment to a type-locked variable. Lazare INEPOLOGLOU Ingénieur Logiciel 2012/2/29 Michael Morris dmgx.mich...@gmail.com Agreed. If conversion can occur without data loss (that is, if the value being assigned is == the value that actually IS assigned) then no error should occur. So int $a = 1; // no error. 1 == 1 so who cares? int $a = 'House'; // error 0 != 'House', so this is a problem. Again, errors should only raise if the final value != source value. On Tue, Feb 28, 2012 at 6:03 PM, Rick WIdmer vch...@developersdesk.com wrote: On 2/28/2012 2:58 PM, Kris Craig wrote: strong int $a = 1; // Converts to 1. May or may not throw an error (I'm still on the fence). It this is an error, it is no longer PHP. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
I agree with Simon on this: On Wed, Feb 29, 2012 at 08:58, Simon Schick simonsimc...@googlemail.com wrote: I'd like to split this discussion in parts: - just type-hint in functions (as we have it with classes and arrays) or bind a variable to a strict type? - should it then also be possible bind variables to a specific class or interface? - should we go for weak or strong types? - the type-hint is also weak in one way because it accepts all that's compatible with the given type. These make a lot more sense in terms of discussion and those who don't agree on having strong type implemented in the language core would probably see value in type-hinting like we have with classes arrays (even if here we enter again in a strong vs. weak discussion). I for once agree it can be useful to have type-hinting for the other types, including throwing an error if there's loss of data in conversion. Although I'm not so sure about having strong types... Regards, Daniel Macedo -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
On Tue, February 28, 2012 5:17 pm, Kris Craig wrote: Some cases I would find interesting to be explained: (using 'streak' for strong and/or weak, feel free to separate the two) streak int $i = 123.456; //Common idiom for floor() streak int $i = 123.456; //In contrast to previous streak int $i = 1 ; //value=1 is ridiculously common HTML It's all well and good to say that any loss of data is bad and to raise some E_* for it, but there are some idioms so common that feel wrong as I consider them... If everyone for the new type hinting/forcing can reach consensus on these sorts of cases, it would help clarify any RFCs a bit, I think wrt E_RECOVERABLE_ERROR vs E_WARNING If current type hinting raises E_RECOVERABLE_ERROR, I have no objection to following that lead, with the explicit caveat that a change to the existing type-hinting to E_WARNING, as unlikely as that seems, would pull the new streak with it. I don't even object to using E_ERROR for the strong variant, if that passes review, really, since strong is, errr, strong. :-) Anybody who doesn't like the E_* can re-define them in a custom error handler anyway, though allowing PHP to continue after E_ERROR is like playing russian roulette... -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
I agree with the notion of typing in function arguments, though I'm not a
fan of this particular approach. Specifically, I don't like the idea of
1aaa throwing one kind of error (E_NOTICE) and array($whatever) throwing
another kind of error. They should both throw the same error because
they're both incompatible types; i.e. 1 == 1 but 1aaa != 1. I don't
like the idea of saying that one incompatible type is worse than
another. I just don't see any value in that and it ultimately just makes
things more confusing and complicated than they need to be for the end-user.
Instead, they should both throw the same kind of error. Whether it's just
E_RECOVERABLE_ERROR or we give the developer a choice by having
strong/weak, I'm fine either way (though I think the second approach adds
more flexibility without any practical drawbacks).
And again, let's avoid using phrases like most people. I'll let
Wikipedia elaborate on why:
http://en.wikipedia.org/wiki/Weasel_word
--Kris
On Wed, Feb 29, 2012 at 2:26 AM, Simon Schick
simonsimc...@googlemail.comwrote:
Hi, Arvids
I did not meant to putt all in one big RFC but more to think about the
connection between these two while developing.
Bye
Simon
2012/2/29 Arvids Godjuks arvids.godj...@gmail.com
Combining different things into one big RFC is not a good idea. It's
hard to develop and test the work it it's in one big chunk.
Decomposition makes it much easier. Type hinting has to have it's own
RFC.
Besides - someone can be willing to do type hinting patch and don't
want to do the object_cast_magic one.
And thanks for the support :)
2012/2/29 Simon Schick simonsimc...@googlemail.com:
Hi,
We could even combine this with the following RFC:
https://wiki.php.net/rfc/object_cast_magic
If an integer is required and you pass an object, it first checks if
this
object is castable to integer ;)
Bye
Simon
2012/2/29 Simon Schick simonsimc...@googlemail.com
Hi, John
I personally do not care about weak or strong variables at all ... I
only
want what Arvids suggested last time:
test(1, 2); // 2;
test(1, 2); // 2
test(1aaa, 2); // E_NOTICE or E_TYPE and result 2
test(array(2), 2); // E_RECOVERABLE_ERROR - just like with array
type
hint now.
It's really what the most people want. Simple, easy to pick up
(object
and array already have this) and is just optional.
I count myself as a part of *most people* in this statement ;)
I'm also quite fine with the current type-hints as you'd anyways get
an
error if you try something like this:
function foo(SimpleClass $a) {
$a-getName();
}
foo(Test);
If you now get *method called from an non-object* or a message that
you
have passed a value that's not compatible with *SimpleClass* ...
I'd like to split this discussion in parts:
- just type-hint in functions (as we have it with classes and
arrays)
or bind a variable to a strict type?
- should it then also be possible bind variables to a specific
class or interface?
- should we go for weak or strong types?
- the type-hint is also weak in one way because it accepts all
that's compatible with the given type.
Bye
Simon
2012/2/29 John Crenshaw johncrens...@priacta.com
I would personally be inclined towards something simpler like
E_NOTICE
or
E_WARNING, but current type hints all raise E_RECOVERABLE_ERROR. I
think we
should be consistent, and the consistency argument may make the
difference.
There may be a strong case for changing the error level on all type
hints
to something simpler (or new, like E_TYPE), but I think that might be
better to tackle that in a separate discussion.
John Crenshaw
Priacta, Inc.
From: Kris Craig [mailto:kris.cr...@gmail.com]
Sent: Tuesday, February 28, 2012 8:40 PM
To: John Crenshaw
Cc: Rick WIdmer; internals@lists.php.net
Subject: Re: [PHP-DEV] Scalar type hinting
I wouldn't mind that, though I'm concerned that it may not be
sellable
because some people on here have expressed a strong opinion that this
shouldn't throw anything more than a notice or a warning at most,
something
that I and others strongly disagree with. The logical approach, to
me
at
least, is to follow the example of include() and require(); i.e.
they're
both identical except that one throws a scary error while the other
one is
just a warning.
I'm fine with just throwing E_RECOVERABLE_ERROR, though I fear that
may
alienate too many people for us to be able to get this through.
Though
it's possible I might be overestimating that factor.
--Kris
On Tue, Feb 28, 2012 at 5:17 PM, John Crenshaw
johncrens...@priacta.com
mailto:johncrens...@priacta.com wrote:
On Tue, Feb 28, 2012 at 3:03 PM, Rick WIdmer
vch...@developersdesk.com
mailto:vch
Re: [PHP-DEV] Scalar type hinting
@Richard I think you made a very good point. Should we treat a float = int mismatch the same as we would a string = int mismatch, or should the former fail more gracefully? I can see good arguments for both. --Kris On Wed, Feb 29, 2012 at 10:02 AM, Richard Lynch c...@l-i-e.com wrote: On Tue, February 28, 2012 5:17 pm, Kris Craig wrote: Some cases I would find interesting to be explained: (using 'streak' for strong and/or weak, feel free to separate the two) streak int $i = 123.456; //Common idiom for floor() streak int $i = 123.456; //In contrast to previous streak int $i = 1 ; //value=1 is ridiculously common HTML It's all well and good to say that any loss of data is bad and to raise some E_* for it, but there are some idioms so common that feel wrong as I consider them... If everyone for the new type hinting/forcing can reach consensus on these sorts of cases, it would help clarify any RFCs a bit, I think wrt E_RECOVERABLE_ERROR vs E_WARNING If current type hinting raises E_RECOVERABLE_ERROR, I have no objection to following that lead, with the explicit caveat that a change to the existing type-hinting to E_WARNING, as unlikely as that seems, would pull the new streak with it. I don't even object to using E_ERROR for the strong variant, if that passes review, really, since strong is, errr, strong. :-) Anybody who doesn't like the E_* can re-define them in a custom error handler anyway, though allowing PHP to continue after E_ERROR is like playing russian roulette... -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
Now that I think of it, this would probably be a good argument for differentiating between strong and weak. Looking back to my previous comment, it probably would be best to have it behave the same regardless of what the incompatible type is. But in the case where a float might sneak its way into an int, the developer might decide that going with a weak type would make it more flexible (though if it was me, I'd just do a round or leave it a mixed type lol). --Kris On Wed, Feb 29, 2012 at 11:09 AM, Kris Craig kris.cr...@gmail.com wrote: @Richard I think you made a very good point. Should we treat a float = int mismatch the same as we would a string = int mismatch, or should the former fail more gracefully? I can see good arguments for both. --Kris On Wed, Feb 29, 2012 at 10:02 AM, Richard Lynch c...@l-i-e.com wrote: On Tue, February 28, 2012 5:17 pm, Kris Craig wrote: Some cases I would find interesting to be explained: (using 'streak' for strong and/or weak, feel free to separate the two) streak int $i = 123.456; //Common idiom for floor() streak int $i = 123.456; //In contrast to previous streak int $i = 1 ; //value=1 is ridiculously common HTML It's all well and good to say that any loss of data is bad and to raise some E_* for it, but there are some idioms so common that feel wrong as I consider them... If everyone for the new type hinting/forcing can reach consensus on these sorts of cases, it would help clarify any RFCs a bit, I think wrt E_RECOVERABLE_ERROR vs E_WARNING If current type hinting raises E_RECOVERABLE_ERROR, I have no objection to following that lead, with the explicit caveat that a change to the existing type-hinting to E_WARNING, as unlikely as that seems, would pull the new streak with it. I don't even object to using E_ERROR for the strong variant, if that passes review, really, since strong is, errr, strong. :-) Anybody who doesn't like the E_* can re-define them in a custom error handler anyway, though allowing PHP to continue after E_ERROR is like playing russian roulette... -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
Hi, Kris
I don't think we have to care about scripts that are written right now if
we're talking about throwing an E_RECOVERABLE_ERROR or E_WARNING because
this feature is completely new. But I like the idea to have all type-hint
failures ending up the same way.
I personally would keep the error-messages for classes and arrays as they
are right now and do the same error in case the given value is not
compatible to the expected type.
Not compatible means that data gets lost after converting the data into the
other data-type.
Lets have an example:
function foo(integer $i) {
// do something
}
foo(true); // Even if Boolean is a lower type than int, it can be easily
casted to an int. It's equivalent to 1.
foo(1); // wont throw an error because the transformation into an integer
is loose-less
foo(2.5); // Throws an E_RECOVERABLE_ERROR because its a float, but an
integer is required here.
foo(horse); // Throws an E_RECOVERABLE_ERROR because if you transform
horse into a float, it's 1 and that's not equal to the string anymore.
I personally would treat float - int miss matches the same way as all other
stuff, because it cannot be converted loose-less.
And if the Object-cast-stuff comes through, we have to think about this in
addition:
https://wiki.php.net/rfc/object_cast_magic
class MyInteger {
public function __castTo(string $type) {
if ($type === integer)
return 5;
}
}
function foo(integer $i) {
// do something
}
foo(new MyInteger()); // Even if this is an object - it's cast-able to an
integer and therefore should be valid
But this is just in case the RFC gets through ;) We don't have to think
that much about it now - just keep it in mind.
Bye
Simon
2012/2/29 Kris Craig kris.cr...@gmail.com
Now that I think of it, this would probably be a good argument for
differentiating between strong and weak. Looking back to my previous
comment, it probably would be best to have it behave the same regardless of
what the incompatible type is. But in the case where a float might sneak
its way into an int, the developer might decide that going with a weak type
would make it more flexible (though if it was me, I'd just do a round or
leave it a mixed type lol).
--Kris
On Wed, Feb 29, 2012 at 11:09 AM, Kris Craig kris.cr...@gmail.com wrote:
@Richard I think you made a very good point. Should we treat a float =
int mismatch the same as we would a string = int mismatch, or should the
former fail more gracefully? I can see good arguments for both.
--Kris
On Wed, Feb 29, 2012 at 10:02 AM, Richard Lynch c...@l-i-e.com wrote:
On Tue, February 28, 2012 5:17 pm, Kris Craig wrote:
Some cases I would find interesting to be explained:
(using 'streak' for strong and/or weak, feel free to separate the two)
streak int $i = 123.456; //Common idiom for floor()
streak int $i = 123.456; //In contrast to previous
streak int $i = 1 ; //value=1 is ridiculously common HTML
It's all well and good to say that any loss of data is bad and to
raise some E_* for it, but there are some idioms so common that feel
wrong as I consider them...
If everyone for the new type hinting/forcing can reach consensus on
these sorts of cases, it would help clarify any RFCs a bit, I think
wrt E_RECOVERABLE_ERROR vs E_WARNING
If current type hinting raises E_RECOVERABLE_ERROR, I have no
objection to following that lead, with the explicit caveat that a
change to the existing type-hinting to E_WARNING, as unlikely as that
seems, would pull the new streak with it.
I don't even object to using E_ERROR for the strong variant, if that
passes review, really, since strong is, errr, strong. :-)
Anybody who doesn't like the E_* can re-define them in a custom error
handler anyway, though allowing PHP to continue after E_ERROR is like
playing russian roulette...
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
@Simon Agreed. That's pretty much what I'm thinking it should look like.
With booleans, I think you have a good point. If 1 or 0 is passed to a
bool, I'd say that should be fine without an error. If you were to pass a
2, though (you insolent bastard!), then it would throw the error.
I think we're getting pretty close to having enough to write an RFC for
this. I'll go ahead and create one after a little more discussion goes
around.
--Kris
On Wed, Feb 29, 2012 at 11:50 AM, Simon Schick
simonsimc...@googlemail.comwrote:
Hi, Kris
I don't think we have to care about scripts that are written right now if
we're talking about throwing an E_RECOVERABLE_ERROR or E_WARNING because
this feature is completely new. But I like the idea to have all type-hint
failures ending up the same way.
I personally would keep the error-messages for classes and arrays as they
are right now and do the same error in case the given value is not
compatible to the expected type.
Not compatible means that data gets lost after converting the data into
the other data-type.
Lets have an example:
function foo(integer $i) {
// do something
}
foo(true); // Even if Boolean is a lower type than int, it can be easily
casted to an int. It's equivalent to 1.
foo(1); // wont throw an error because the transformation into an
integer is loose-less
foo(2.5); // Throws an E_RECOVERABLE_ERROR because its a float, but an
integer is required here.
foo(horse); // Throws an E_RECOVERABLE_ERROR because if you transform
horse into a float, it's 1 and that's not equal to the string anymore.
I personally would treat float - int miss matches the same way as all
other stuff, because it cannot be converted loose-less.
And if the Object-cast-stuff comes through, we have to think about this in
addition:
https://wiki.php.net/rfc/object_cast_magic
class MyInteger {
public function __castTo(string $type) {
if ($type === integer)
return 5;
}
}
function foo(integer $i) {
// do something
}
foo(new MyInteger()); // Even if this is an object - it's cast-able to an
integer and therefore should be valid
But this is just in case the RFC gets through ;) We don't have to think
that much about it now - just keep it in mind.
Bye
Simon
2012/2/29 Kris Craig kris.cr...@gmail.com
Now that I think of it, this would probably be a good argument for
differentiating between strong and weak. Looking back to my previous
comment, it probably would be best to have it behave the same regardless
of
what the incompatible type is. But in the case where a float might sneak
its way into an int, the developer might decide that going with a weak
type
would make it more flexible (though if it was me, I'd just do a round or
leave it a mixed type lol).
--Kris
On Wed, Feb 29, 2012 at 11:09 AM, Kris Craig kris.cr...@gmail.com
wrote:
@Richard I think you made a very good point. Should we treat a float =
int mismatch the same as we would a string = int mismatch, or should
the
former fail more gracefully? I can see good arguments for both.
--Kris
On Wed, Feb 29, 2012 at 10:02 AM, Richard Lynch c...@l-i-e.com wrote:
On Tue, February 28, 2012 5:17 pm, Kris Craig wrote:
Some cases I would find interesting to be explained:
(using 'streak' for strong and/or weak, feel free to separate the two)
streak int $i = 123.456; //Common idiom for floor()
streak int $i = 123.456; //In contrast to previous
streak int $i = 1 ; //value=1 is ridiculously common HTML
It's all well and good to say that any loss of data is bad and to
raise some E_* for it, but there are some idioms so common that feel
wrong as I consider them...
If everyone for the new type hinting/forcing can reach consensus on
these sorts of cases, it would help clarify any RFCs a bit, I think
wrt E_RECOVERABLE_ERROR vs E_WARNING
If current type hinting raises E_RECOVERABLE_ERROR, I have no
objection to following that lead, with the explicit caveat that a
change to the existing type-hinting to E_WARNING, as unlikely as that
seems, would pull the new streak with it.
I don't even object to using E_ERROR for the strong variant, if that
passes review, really, since strong is, errr, strong. :-)
Anybody who doesn't like the E_* can re-define them in a custom error
handler anyway, though allowing PHP to continue after E_ERROR is like
playing russian roulette...
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
And here's a thought: I could structure the RFC so that the voting will
have 3 choices: Yes with strong/weak differentiation, yes without
strong/weak, or no. However, the voting RFC doesn't cover how the tally
should be calculated in such a circumstance. For example, let's say we had
8 votes yes with differentiation, 2 votes yes without differentiation, and
5 votes no. If we tally the two yes columns, it's 10 - 5, which would be
the required 2/3 majority. However, how would we calculate the mandate on
differentiation? Among those who voted yes, there's a clear 8 - 2 (80%)
majority in favor of it. But if you count the no votes as being no to
differentiation and add them to the total, it suddenly becomes 8 - 7, which
falls short of the 2/3 majority. An argument could be made that these
people who voted no would not want differentiation, but another argument
could be made that; while they don't like the idea, if it does happen
they'd rather have it differentiated than not. In other words, determining
voter intent from that group would be difficult and thus only tallying
among the yes votes would make sense. Both arguments would have about
equal merit I think
The voting RFC does allow for different options in the vote, but it does
not elaborate on this. We could break the no group into two as well,
though that could make things a bit too confusing.
Since there's presently no clear procedure on this (at least none that I'm
aware of), what are your thoughts on this? I do believe the two should be
in the same vote since they're pretty integral to one another, but I'm not
sure how best to do that while maintaining accurate results without making
it too complicated.
--Kris
On Wed, Feb 29, 2012 at 12:18 PM, Kris Craig kris.cr...@gmail.com wrote:
@Simon Agreed. That's pretty much what I'm thinking it should look like.
With booleans, I think you have a good point. If 1 or 0 is passed to a
bool, I'd say that should be fine without an error. If you were to pass a
2, though (you insolent bastard!), then it would throw the error.
I think we're getting pretty close to having enough to write an RFC for
this. I'll go ahead and create one after a little more discussion goes
around.
--Kris
On Wed, Feb 29, 2012 at 11:50 AM, Simon Schick
simonsimc...@googlemail.com wrote:
Hi, Kris
I don't think we have to care about scripts that are written right now if
we're talking about throwing an E_RECOVERABLE_ERROR or E_WARNING because
this feature is completely new. But I like the idea to have all type-hint
failures ending up the same way.
I personally would keep the error-messages for classes and arrays as they
are right now and do the same error in case the given value is not
compatible to the expected type.
Not compatible means that data gets lost after converting the data into
the other data-type.
Lets have an example:
function foo(integer $i) {
// do something
}
foo(true); // Even if Boolean is a lower type than int, it can be easily
casted to an int. It's equivalent to 1.
foo(1); // wont throw an error because the transformation into an
integer is loose-less
foo(2.5); // Throws an E_RECOVERABLE_ERROR because its a float, but an
integer is required here.
foo(horse); // Throws an E_RECOVERABLE_ERROR because if you transform
horse into a float, it's 1 and that's not equal to the string anymore.
I personally would treat float - int miss matches the same way as all
other stuff, because it cannot be converted loose-less.
And if the Object-cast-stuff comes through, we have to think about this
in addition:
https://wiki.php.net/rfc/object_cast_magic
class MyInteger {
public function __castTo(string $type) {
if ($type === integer)
return 5;
}
}
function foo(integer $i) {
// do something
}
foo(new MyInteger()); // Even if this is an object - it's cast-able to
an integer and therefore should be valid
But this is just in case the RFC gets through ;) We don't have to think
that much about it now - just keep it in mind.
Bye
Simon
2012/2/29 Kris Craig kris.cr...@gmail.com
Now that I think of it, this would probably be a good argument for
differentiating between strong and weak. Looking back to my previous
comment, it probably would be best to have it behave the same regardless
of
what the incompatible type is. But in the case where a float might sneak
its way into an int, the developer might decide that going with a weak
type
would make it more flexible (though if it was me, I'd just do a round or
leave it a mixed type lol).
--Kris
On Wed, Feb 29, 2012 at 11:09 AM, Kris Craig kris.cr...@gmail.com
wrote:
@Richard I think you made a very good point. Should we treat a float
=
int mismatch the same as we would a string = int mismatch, or should
the
former fail more gracefully? I can see good arguments for both.
--Kris
On Wed, Feb 29, 2012 at 10:02 AM, Richard Lynch c...@l-i-e.com wrote:
On
Re: [PHP-DEV] Scalar type hinting
Hi, Kris
As we have some RFCs around that we should update them I think.
In my opinion we should split them up into 3 RFCs (and one grouping RFC):
Weak and strong type-checks (whatever that in detail means) should be
discussed in one single RFC. The option1 in the existing one is pretty
close to what I expect it to be - but why should f.e. 12abc be a valid
integer? As said - we should update that.
https://wiki.php.net/rfc/typecheckingstrictandweak
Split the following RFC into two RFCs. Parameter type-hint and return
type-hint:
https://wiki.php.net/rfc/typehint
Until now we have two RFCs for return type-hint that should also be
combined. Add the information from the last mentioned here as well:
https://wiki.php.net/rfc/returntypehint2
https://wiki.php.net/rfc/returntypehint
And finally update the grouping-RFC:
https://wiki.php.net/rfc/typechecking
The RFCs for parameter- and return-type-hint should not contain the
definition of strict or weak type-hints.
After all three RFCs have been voted by a bunch of people we can write down
a RFC for a combination - f.e. how it should look like to have weak
function type-hinting or strong return type-hinting.
So .. here's quite a lot of work to do to gather the people who wrote these
RFCs and let their ideas float into one specific definition with several
options how to implement them.
Bye
Simon
2012/2/29 Kris Craig kris.cr...@gmail.com
And here's a thought: I could structure the RFC so that the voting will
have 3 choices: Yes with strong/weak differentiation, yes without
strong/weak, or no. However, the voting RFC doesn't cover how the tally
should be calculated in such a circumstance. For example, let's say we had
8 votes yes with differentiation, 2 votes yes without differentiation, and
5 votes no. If we tally the two yes columns, it's 10 - 5, which would be
the required 2/3 majority. However, how would we calculate the mandate on
differentiation? Among those who voted yes, there's a clear 8 - 2 (80%)
majority in favor of it. But if you count the no votes as being no to
differentiation and add them to the total, it suddenly becomes 8 - 7, which
falls short of the 2/3 majority. An argument could be made that these
people who voted no would not want differentiation, but another argument
could be made that; while they don't like the idea, if it does happen
they'd rather have it differentiated than not. In other words, determining
voter intent from that group would be difficult and thus only tallying
among the yes votes would make sense. Both arguments would have about
equal merit I think
The voting RFC does allow for different options in the vote, but it does
not elaborate on this. We could break the no group into two as well,
though that could make things a bit too confusing.
Since there's presently no clear procedure on this (at least none that I'm
aware of), what are your thoughts on this? I do believe the two should be
in the same vote since they're pretty integral to one another, but I'm not
sure how best to do that while maintaining accurate results without making
it too complicated.
--Kris
On Wed, Feb 29, 2012 at 12:18 PM, Kris Craig kris.cr...@gmail.com wrote:
@Simon Agreed. That's pretty much what I'm thinking it should look like.
With booleans, I think you have a good point. If 1 or 0 is passed to a
bool, I'd say that should be fine without an error. If you were to pass a
2, though (you insolent bastard!), then it would throw the error.
I think we're getting pretty close to having enough to write an RFC for
this. I'll go ahead and create one after a little more discussion goes
around.
--Kris
On Wed, Feb 29, 2012 at 11:50 AM, Simon Schick
simonsimc...@googlemail.com wrote:
Hi, Kris
I don't think we have to care about scripts that are written right now
if we're talking about throwing an E_RECOVERABLE_ERROR or E_WARNING because
this feature is completely new. But I like the idea to have all type-hint
failures ending up the same way.
I personally would keep the error-messages for classes and arrays as
they are right now and do the same error in case the given value is not
compatible to the expected type.
Not compatible means that data gets lost after converting the data into
the other data-type.
Lets have an example:
function foo(integer $i) {
// do something
}
foo(true); // Even if Boolean is a lower type than int, it can be easily
casted to an int. It's equivalent to 1.
foo(1); // wont throw an error because the transformation into an
integer is loose-less
foo(2.5); // Throws an E_RECOVERABLE_ERROR because its a float, but an
integer is required here.
foo(horse); // Throws an E_RECOVERABLE_ERROR because if you transform
horse into a float, it's 1 and that's not equal to the string anymore.
I personally would treat float - int miss matches the same way as all
other stuff, because it cannot be converted loose-less.
And if the Object-cast-stuff
RE: [PHP-DEV] Scalar type hinting
Guys, I've followed this thread silently so far, and I'm wondering what changed over the last ~1.5years that warrants a new discussion into that matter. I think the previous discussion ended with a pretty clear directive that strict typing has no place in PHP. Rasmus said about the proposal back then They aren't hints. It is strict typing and in its current form I would ask you guys not to call the 5.4 release PHP. - which put in one sentence what several others (myself included) put in many more words. So the 'strong'/'firm'/'strict'/whatnot version of what is being discussed here, should probably not be discussed at all. We've been through it, and rejected it. Back when we rejected strict typing, we also 'killed' the other RFC[*] that was born out of that old discussion - the 'weak' auto-conversion RFC. If I recall correctly, it was for two reasons - one was that the proponents of the strict typing said they'll firmly object weak typing, and the other is that this RFC still had some issues that didn't seem obvious to hammer out (main one I recall is that sticking to PHP's standard type juggling rules meant that feature wasn't very useful, and we didn't feel very comfortable introducing brand new type juggling rules just for that feature). If you want to revive that discussion, I suggest you take a look at that RFC - confine yourselves to only work on stuff that stands a chance to get accepted (no strict typing) - and try to come up with good answers to the open questions. No point in redoing the whole discussion from scratch. Zeev [*]https://wiki.php.net/rfc/typecheckingstrictandweak -Original Message- From: Kris Craig [mailto:kris.cr...@gmail.com] Sent: Tuesday, February 28, 2012 11:58 PM To: John Crenshaw Cc: Richard Lynch; internals@lists.php.net Subject: Re: [PHP-DEV] Scalar type hinting Err sorry yes John is correct. I wasn't paying close enough attention. Here's *my* vision of how that progression would look: $a = 1; // Current kosher unchanged. weak int $a = 1; // Converts to 1. No error thrown. strong int $a = 1; // Converts to 1. May or may not throw an error (I'm still on the fence). $a = blah; // Current kosher unchanged. weak int $a = blah; // Throws E_x error level. strong int $a = blah; // Throws E_y error level. Where E_y E_x. --Kris On Tue, Feb 28, 2012 at 1:52 PM, John Crenshaw johncrens...@priacta.comwrote: No, In the example given there's an error on int $a = 1. There should be no error because this juggles fine. John Crenshaw Priacta, inc. -Original Message- From: Kris Craig [mailto:kris.cr...@gmail.com] Sent: Tuesday, February 28, 2012 4:47 PM To: Richard Lynch Cc: internals@lists.php.net Subject: Re: [PHP-DEV] Scalar type hinting @Richard That's fairly close to what I'm thinking, yes. But there seems to be a diverse range of ideas bouncing around right now, so at present it's all in flux. --Kris On Tue, Feb 28, 2012 at 1:44 PM, Richard Lynch c...@l-i-e.com wrote: On Mon, February 27, 2012 4:34 pm, Kris Craig wrote: I think this is the main reason for differentiating between strong (or whatever word is appropriate) and weak. The developer may very well want their script to blow-up in such a case. I believe I actually get it now... You want 3 layers: $a = 1; //current kosher unchanged weak int $a = 1; // some E_x error level strong int $a = 1; // some E_y error level where E_y E_x Is that a correct summation? -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id =F S9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
Aand here we go again. Every few days it seems, somebody jumps into this thread and reminds us that strict typing is a bad idea, despite the fact that we've already all agreed on that point about a gazillion times. As for past RFC's, I would recommend you review the voting procedure. If an RFC is rejected, the policy does allow it to be re-introduced after 6 months. While we're not actually reviving a previously rejected RFC since we're discussing a different approach, even if you were to apply that to the broader conceptual level, this discussion is still perfectly kosher since, as you said, that rejection happened 1.5 years ago (3 times the required period). Sorry if my tone is a bit frustrated, but I think we're all a bit annoyed at this repetitive pattern by now. We start finding common ground and making progress, then somebody new makes a post about the evils of strict typing and questioning why we're talking about this, obviously completely ignoring the fact that we've already addressed this *numerous* times. So Zeev, while I appreciate your interest and welcome you to participate, please take another look at the previous posts in this thread, because we have already addressed your concerns ad nauseum and have since moved-on. I do not want us to get dragged back into grinding our wheels in the mud on that. Thank you for your understanding. --Kris On Wed, Feb 29, 2012 at 1:09 PM, Zeev Suraski z...@zend.com wrote: Guys, I've followed this thread silently so far, and I'm wondering what changed over the last ~1.5years that warrants a new discussion into that matter. I think the previous discussion ended with a pretty clear directive that strict typing has no place in PHP. Rasmus said about the proposal back then They aren't hints. It is strict typing and in its current form I would ask you guys not to call the 5.4 release PHP. - which put in one sentence what several others (myself included) put in many more words. So the 'strong'/'firm'/'strict'/whatnot version of what is being discussed here, should probably not be discussed at all. We've been through it, and rejected it. Back when we rejected strict typing, we also 'killed' the other RFC[*] that was born out of that old discussion - the 'weak' auto-conversion RFC. If I recall correctly, it was for two reasons - one was that the proponents of the strict typing said they'll firmly object weak typing, and the other is that this RFC still had some issues that didn't seem obvious to hammer out (main one I recall is that sticking to PHP's standard type juggling rules meant that feature wasn't very useful, and we didn't feel very comfortable introducing brand new type juggling rules just for that feature). If you want to revive that discussion, I suggest you take a look at that RFC - confine yourselves to only work on stuff that stands a chance to get accepted (no strict typing) - and try to come up with good answers to the open questions. No point in redoing the whole discussion from scratch. Zeev [*]https://wiki.php.net/rfc/typecheckingstrictandweak -Original Message- From: Kris Craig [mailto:kris.cr...@gmail.com] Sent: Tuesday, February 28, 2012 11:58 PM To: John Crenshaw Cc: Richard Lynch; internals@lists.php.net Subject: Re: [PHP-DEV] Scalar type hinting Err sorry yes John is correct. I wasn't paying close enough attention. Here's *my* vision of how that progression would look: $a = 1; // Current kosher unchanged. weak int $a = 1; // Converts to 1. No error thrown. strong int $a = 1; // Converts to 1. May or may not throw an error (I'm still on the fence). $a = blah; // Current kosher unchanged. weak int $a = blah; // Throws E_x error level. strong int $a = blah; // Throws E_y error level. Where E_y E_x. --Kris On Tue, Feb 28, 2012 at 1:52 PM, John Crenshaw johncrens...@priacta.comwrote: No, In the example given there's an error on int $a = 1. There should be no error because this juggles fine. John Crenshaw Priacta, inc. -Original Message- From: Kris Craig [mailto:kris.cr...@gmail.com] Sent: Tuesday, February 28, 2012 4:47 PM To: Richard Lynch Cc: internals@lists.php.net Subject: Re: [PHP-DEV] Scalar type hinting @Richard That's fairly close to what I'm thinking, yes. But there seems to be a diverse range of ideas bouncing around right now, so at present it's all in flux. --Kris On Tue, Feb 28, 2012 at 1:44 PM, Richard Lynch c...@l-i-e.com wrote: On Mon, February 27, 2012 4:34 pm, Kris Craig wrote: I think this is the main reason for differentiating between strong (or whatever word is appropriate) and weak. The developer may very well want their script to blow-up in such a case. I believe I actually get it now... You want 3 layers: $a = 1; //current kosher unchanged weak int $a = 1; // some E_x
Re: [PHP-DEV] Scalar type hinting
Personally, while I see the value in recycling what's already there, I think that would just make things WAY more confusing than they need to be. Some of these RFC's are years old and appear to have since been abandoned. I think it would be better to have a procedure for removing dead RFC's after a certain period of inactivity (like 6 months). In any case, given the complexity involved, I think it would make much more sense to create an RFC from scratch. Since the strong/weak question is integral to this, having them in separate RFC's wouldn't work I don't think. For example, what if the strong/weak one passed, but the one about type hinting failed? I think that would just set a bad precedent for the RFC process, since currently we don't have a system for having RFC dependencies. Hence why I think the most sensible approach is to do this in one single vote. The question is, how should that vote be structured? I think what we need to do is amend the voting process before tackling this, because there's just no good way to handle this right now without arbitrarily creating a majority standard that doesn't currently exist. So, here's what I'm thinking: An RFC can contain one primary question and zero or more secondary questions. The primary question would be the way it's setup now; all those rules would be unchanged. However, what if there are multiple approaches to *how* this RFC can be implemented? It stands to reason that, for example, a clear 2/3 majority can agree that this should be implemented, but there is no clear majority with regard to which method should be used. The more options there are, the more likely it is that the vote will be perpetually split, essentially preventing that feature from moving forward despite having supermajority support. Therefore, a secondary question would be defined as a question that does not materially affect *anything* outside the immediate scope of the primary question and does not contain any voting options that would prevent the primary question from being implemented. As such, since the secondary question can have a theoretical infinite number of possible answers, the standard for passage would be a simple plurality; i.e. whichever option has the most votes would be the one used to implement the primary question, if passed (if the primary question fails, then the secondary question is meaningless). In the event of a tie, I would say extend the voting period until someone breaks the tie. What do you think? I believe this would not only be helpful to us now, but would also improve the RFC voting process overall by making it much more flexible. I can write an RFC for this if anyone thinks it has merit. --Kris On Wed, Feb 29, 2012 at 12:57 PM, Simon Schick simonsimc...@googlemail.comwrote: Hi, Kris As we have some RFCs around that we should update them I think. In my opinion we should split them up into 3 RFCs (and one grouping RFC): Weak and strong type-checks (whatever that in detail means) should be discussed in one single RFC. The option1 in the existing one is pretty close to what I expect it to be - but why should f.e. 12abc be a valid integer? As said - we should update that. https://wiki.php.net/rfc/typecheckingstrictandweak Split the following RFC into two RFCs. Parameter type-hint and return type-hint: https://wiki.php.net/rfc/typehint Until now we have two RFCs for return type-hint that should also be combined. Add the information from the last mentioned here as well: https://wiki.php.net/rfc/returntypehint2 https://wiki.php.net/rfc/returntypehint And finally update the grouping-RFC: https://wiki.php.net/rfc/typechecking The RFCs for parameter- and return-type-hint should not contain the definition of strict or weak type-hints. After all three RFCs have been voted by a bunch of people we can write down a RFC for a combination - f.e. how it should look like to have weak function type-hinting or strong return type-hinting. So .. here's quite a lot of work to do to gather the people who wrote these RFCs and let their ideas float into one specific definition with several options how to implement them. Bye Simon 2012/2/29 Kris Craig kris.cr...@gmail.com And here's a thought: I could structure the RFC so that the voting will have 3 choices: Yes with strong/weak differentiation, yes without strong/weak, or no. However, the voting RFC doesn't cover how the tally should be calculated in such a circumstance. For example, let's say we had 8 votes yes with differentiation, 2 votes yes without differentiation, and 5 votes no. If we tally the two yes columns, it's 10 - 5, which would be the required 2/3 majority. However, how would we calculate the mandate on differentiation? Among those who voted yes, there's a clear 8 - 2 (80%) majority in favor of it. But if you count the no votes as being no to differentiation and add them to the total, it suddenly becomes 8 - 7, which falls short of
RE: [PHP-DEV] Scalar type hinting
Kris, If we've agreed that strict typing is bad, why is it even showing on the discussion here? Calling it 'firm' or 'strong' doesn't make a difference. If it errors out or throws an exception (which BTW is out of the question for a language feature), it's strict typing, regardless of naming. Thanks for pointing me to the voting procedure that I helped author. Are you essentially telling us we all have to waste our time again just because 6 months have passed? That alone might be reason enough to turn the OR in there into an AND and shut down that loophole. The rationale behind that time period was to allow for cases where there was an 'almost' majority. Here, the proposal stands no chance. The only reason you're not seeing anybody from the core devs responding is because they're tired of the Nth incarnation of the same discussion happening again with zero new ideas. If you can show why it makes sense to revive the discussion based on the 2nd bullet, that is: The author(s) make substantial changes to the proposal. While it's impossible to put clear definitions on what constitutes 'substantial' changes, they should be material enough so that they'll significantly effect the outcome of another vote. ... then it's worth discussing. Nothing I saw in this thread falls under that category, as far as I can tell. Let's put it to rest. Zeev From: Kris Craig [mailto:kris.cr...@gmail.com] Sent: Wednesday, February 29, 2012 11:18 PM To: Zeev Suraski Cc: John Crenshaw; Richard Lynch; internals@lists.php.net Subject: Re: [PHP-DEV] Scalar type hinting Aand here we go again. Every few days it seems, somebody jumps into this thread and reminds us that strict typing is a bad idea, despite the fact that we've already all agreed on that point about a gazillion times. As for past RFC's, I would recommend you review the voting procedure. If an RFC is rejected, the policy does allow it to be re-introduced after 6 months. While we're not actually reviving a previously rejected RFC since we're discussing a different approach, even if you were to apply that to the broader conceptual level, this discussion is still perfectly kosher since, as you said, that rejection happened 1.5 years ago (3 times the required period). Sorry if my tone is a bit frustrated, but I think we're all a bit annoyed at this repetitive pattern by now. We start finding common ground and making progress, then somebody new makes a post about the evils of strict typing and questioning why we're talking about this, obviously completely ignoring the fact that we've already addressed this numerous times. So Zeev, while I appreciate your interest and welcome you to participate, please take another look at the previous posts in this thread, because we have already addressed your concerns ad nauseum and have since moved-on. I do not want us to get dragged back into grinding our wheels in the mud on that. Thank you for your understanding. --Kris On Wed, Feb 29, 2012 at 1:09 PM, Zeev Suraski z...@zend.commailto:z...@zend.com wrote: Guys, I've followed this thread silently so far, and I'm wondering what changed over the last ~1.5years that warrants a new discussion into that matter. I think the previous discussion ended with a pretty clear directive that strict typing has no place in PHP. Rasmus said about the proposal back then They aren't hints. It is strict typing and in its current form I would ask you guys not to call the 5.4 release PHP. - which put in one sentence what several others (myself included) put in many more words. So the 'strong'/'firm'/'strict'/whatnot version of what is being discussed here, should probably not be discussed at all. We've been through it, and rejected it. Back when we rejected strict typing, we also 'killed' the other RFC[*] that was born out of that old discussion - the 'weak' auto-conversion RFC. If I recall correctly, it was for two reasons - one was that the proponents of the strict typing said they'll firmly object weak typing, and the other is that this RFC still had some issues that didn't seem obvious to hammer out (main one I recall is that sticking to PHP's standard type juggling rules meant that feature wasn't very useful, and we didn't feel very comfortable introducing brand new type juggling rules just for that feature). If you want to revive that discussion, I suggest you take a look at that RFC - confine yourselves to only work on stuff that stands a chance to get accepted (no strict typing) - and try to come up with good answers to the open questions. No point in redoing the whole discussion from scratch. Zeev [*]https://wiki.php.net/rfc/typecheckingstrictandweak -Original Message- From: Kris Craig [mailto:kris.cr...@gmail.commailto:kris.cr...@gmail.com] Sent: Tuesday, February 28, 2012 11:58 PM To: John Crenshaw Cc: Richard Lynch; internals@lists.php.netmailto:internals@lists.php.net Subject: Re: [PHP-DEV
Re: [PHP-DEV] Scalar type hinting
Kris Craig wrote: With booleans, I think you have a good point. If 1 or 0 is passed to a bool, I'd say that should be fine without an error. If you were to pass a 2, though (you insolent bastard!), then it would throw the error. I have to complain about that. There is nothing wrong in my book with assuming that a returned value is true while an empty return is false. Having to check for a number greater than zero rather than just 'true' is complicating things again. If it returned some values from the DB query it's 'not false' and we can go on. But my main concern/complaint here is that I am more than happy with my IDE doing all of the type hinting that I need, so there is no need to load down the runtime engine with this. Perhaps now is the time to make a formal request that a lot of this 'compiler' like construction show have an overall 'off' switch so we can run scripts faster? PHPEclipse picks up the phpdoc comment blocks and gives a hint popup that has served me well for years. I know that there are always those say 'you do not have to use it', but with these extensions starting to be applied to the very libraries we rely on, then we are forced to learn about things that we do not actually need in production, and once again we are wasting time on 'keeping up' when all we want is a reliable stable base we can rely on. I'm being forced to accept Smarty3 because 'that is the supported version' when converting several years worth of Smarty2 templates is totally impractical. And libraries like Smarty3 tend to include the very constructs you are discussing 'because they are the modern way'. Perhaps it is about time us old fuddy duddys started to support a frozen stable version of PHP and it's libraries that just get essential security updates and let you 'modern guys' get on with your own branch . -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
Guys, you probably are too deep into the discussion that you haven't noticed an elephant Zeev has put into the room. When the RFC procces was put in place there was a rule outlined - if core devs decide to reject, it's rejected. And as Zeev said last time core dev team decided that there will be no strict typing in PHP, period (btw, Zeev thanks for reminding that). It's open source - if you want it badly, fork, patch and have your party with black jack and girls. Zeev i have just have one question - is it worth trying to get the type hinting the PHP way (that converting thing that errors only on really bad missmatches like asking for int and getting an array or object)? I understand the argument that if rules of conversion are not changed, then basically not much is changed. But from the code writing prespective it becomes easier, because with converting type hint you do not need to make explict conversions all over the code - it's done at calll time and that simplifies things, sometimes a lot. Second - the reflection then does not rely on phpdoc to get the types (and i remember there was an issue with opcode caching and phpdoc being stripped and so not avaliable). It good to have array and object hints, but i miss the integer/string/boolean/double hints more times than i want to admit really :-)
Re: [PHP-DEV] Scalar type hinting
Responses inline. --Kris On Wed, Feb 29, 2012 at 1:49 PM, Zeev Suraski z...@zend.com wrote: Kris, ** ** If we’ve agreed that strict typing is bad, why is it even showing on the discussion here? Calling it ‘firm’ or ‘strong’ doesn’t make a difference. If it errors out or throws an exception (which BTW is out of the question for a language feature), it’s strict typing, regardless of naming. That is a form of cognitive dissonance, a logical fallacy. More colloquially known as an either or argument. Everyone agrees that strict C-like typing is not tenable. We've moved past that and what's being proposed now does not rise to that level. ** ** Thanks for pointing me to the voting procedure that I helped author. You're welcome. Are you essentially telling us we all have to waste our time again just because 6 months have passed? Yes. Though given how many people have shown an interest in this thread, I would challenge your assertion that it is a waste of time. If you feel as though it's a waste of *your* time, then don't waste your time. But that doesn't give you the right to demand that we cease talking about it just because *you* don't think it's a worthy discussion. That alone might be reason enough to turn the OR in there into an AND and shut down that loophole. You're free to introduce a new RFC for that, but don't be surprised when I and probably a number of others campaign heavily and tirelessly against it. I don't think most people would agree with such a totalitarian approach designed to silence dissenting views from being introduced and discussed. The rationale behind that time period was to allow for cases where there was an ‘almost’ majority. Here, the proposal stands no chance. The only reason you’re not seeing anybody from the core devs responding is because they’re tired of the Nth incarnation of the same discussion happening again with zero new ideas. Please refer to the Wikipedia link I posted above pertaining to weasel words. Just because a conceptually similar proposal failed two years ago doesn't mean the discussion we're having now won't have any support. ** ** If you can show why it makes sense to revive the discussion based on the 2 nd bullet, that is: The author(s) make substantial changes to the proposal. While it's impossible to put clear definitions on what constitutes 'substantial' changes, they should be material enough so that they'll significantly effect the outcome of another vote. ** ** … then it’s worth discussing. Nothing I saw in this thread falls under that category, as far as I can tell. I disagree. A number of ideas have been put forth that differ from previous proposals. Just because *you* don't think they differ enough does not mean you can unilaterally declare that this discussion must end. Besides, as you said, such a standard would be completely arbitrary and open to interpretation. It would ultimately be something that would have to come down to a vote (unless you're planning on being the one who gets to decide for the rest of us what's substantial and what's not), which would render the whole argument pointless anyway, since it would essentially be a vote on whether or not we should have a vote. That's how the United States Congress typically operates, and we all know how effective they are ** ** Let’s put it to rest. This issue isn't going away. Again, we've already addressed this in previous posts. You may not want to discuss it, and there may be people who share your sentiment, but that does not give you the authority to shut down this conversation or declare that you're going to change the RFC rules so that we can't vote on this. If that's not what you were proposing, then please accept my apologies for the misunderstanding. Either way, I've already promised to push back hard against any efforts to silence the discussion this time around, and I intend to honor that promise. I am still in favor of ultimately moving this conversation to a separate location if people like Zeev are just tired of having this in their inboxes. Plus it would give those of us who are actually interested in this a place to brainstorm without old fear tactics periodically being reintroduced in an effort to derail the conversation. I'll investigate such options as soon as I have some spare moments. It's been a busy week. =) ** ** Zeev ** ** *From:* Kris Craig [mailto:kris.cr...@gmail.com] *Sent:* Wednesday, February 29, 2012 11:18 PM *To:* Zeev Suraski *Cc:* John Crenshaw; Richard Lynch; internals@lists.php.net *Subject:* Re: [PHP-DEV] Scalar type hinting ** ** Aand here we go again. Every few days it seems, somebody jumps into this thread and reminds us that strict typing is a bad idea, despite the fact that we've already all agreed on that point about a gazillion times. As for past RFC's, I would recommend you
Re: [PHP-DEV] Scalar type hinting
Kris i have a question for you - who will implement a test patch? Previous tries failed not because no one wanted, but because it was damn hard and tricky. And ofcourse there was resistance against strict type hinting. Mine included. I doubt any of the last timeinvolved will be willing to do that again. So that is it: who has the skill, knowlage and will to do that knowing there is very big chance it will be rejected?
