# Flexible type hinting - Thread: https://externals.io/message/44619 - Original archive: https://news-web.php.net/php.internals/44619 - Started by Paul Biggar on 2009-07-02T02:35:57+00:00 - Messages: 38 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/44619.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #44619 — Paul Biggar — 2009-07-02T02:35:57+00:00 URL: https://externals.io/message/44619#44619 Hi folks, Thanks to Ilia for getting to ball rolling on scalar type hinting. It seems there are 3 camps: - (C) the type checking camp: "when I say 'int' I mean 'int'". This is what Ilia's patch does. - (H) the type hinting crowd: 'int' is a hint to the user that an int is expected. This gels well with PHP's weakly typed scalars. I think few people are in this crowd, but a lot of the (S) crowd are mistakenly thought to be. - (S) the "sensible" middle: 'int' means an integer of course. The manual is written somewhere between (S) and (H). I believe I have a solution that caters to each crowd, without being too complicated. There are advantages and disadvantage to all of these: - The main disadvantage of each system is that it doesnt provide what the other systems allow. Strong is too strong for many. Weak is too weak for most. - Ilia had a very good point against (H), which is that many functions return `NULL` or FALSE, and there are lots of errors when these are automatically (and silently) converted to 0 or "". (H) will not catch anything. - A strong argument against (C) is that this currently has no parallel with how scalars are handled in PHP currently. - A (I think weak) argument for (C) is that this is how object type hinting works - An argument for (H)/(S) is that the manual has been written in this style, using this syntax. - A good argument against (C) is that it cannot be used to hint PHP's builtin functions. - The (C) crowd suggested numeric and scalar to the (H) crowd, but I dont think they were impressed. - I dont think there is a strong case for a strongly typed bool. Here is the solution: By default, use (S). The semantics of (S) are roughly provided in a table at the bottom. The idea is that for ints, we take "5", and 5, and fail on "str", FALSE, resource, etc. Allow a very easy way to get (C) and (H) using '+' and '-'. "+int" means fail on anything but an int. This is (C). "-int" means "I expect an int, but I'll take whatever you give me, and cast it to an int". This is (H). (H) is for those times where neither (C) nor (S) are suitable, which occurs in the standard library a lot. I hope that it wouldnt be used much otherwise. With each case, the function author can expect that they if they ask for X, they will get an X. I think numeric isnt required anymore, which is good. Example: function add_user (+string name, string phone_number, int age, +int friend_count, resource photo) { ... } We may bike shed for a while about the choice of +/- vs "strict int" or "weak int", as well as some of the choices in (S). Lets argue about the overall idea first, and get to specifics later. If people like this, I can work on the patch. Thanks, Paul ***** This is a suggested semantics for (S) ******** Each line is in the form: "Run-time type -> type hint = result". You may read "x -> y = z" as "an x passed to a hinted parameter y gives a z". * means all types I didn't mention explicitly. ?? means reasonable people may disagree. I would lean towards FAIL in these cases. array -> array = array * -> array = FAIL numeric string -> int = cast to int real -> int = cast to int int -> int = int * -> int = FAIL int -> numeric = int real -> numeric = real string -> numeric = real/int bool -> numeric = ?? * -> numeric = FAIL int -> bool = bool bool -> bool = bool null -> bool = false real -> bool = bool string -> bool = bool * -> bool = ?? null -> null = null * -> null = FAIL array -> scalar = FAIL int -> scalar = int bool -> scalar = bool null -> scalar = null real -> scalar = real string -> scalar = string resource -> scalar = FAIL object -> scalar = FAIL MyObj -> scalar = FAIL * -> mixed = * int -> real = real real -> real = real numeric string -> real = real * -> real = FAIL array -> string = FAIL int -> string = string bool -> string = FAIL null -> string = FAIL real -> string = string string -> string = string resource -> string = FAIL object -> string = __toString() or FAIL resource -> resource = resource * -> resource = FAIL object -> object = object MyObj -> object = MyObj * -> object = FAIL MyObj -> MyObj = MyObj * -> MyObj = FAIL ***** This is a suggested semantics for (H) ******** Whatever is passed will be cast to whatever you ask for, using existing casting rules, even if thats stupid. ***** This is a suggested semantics for (H) ******** If you ask for X, it must be X, except: object with __toString() -> string = string Anything else is FAIL (which I believe is an E_RECOVERABLE_ERROR). -- Paul Biggar paul.biggar@gmail.com --- ## #44620 — Ilia Alshanetsky — 2009-07-02T04:26:57+00:00 URL: https://externals.io/message/44619#44620 · In reply to: #44619 > - A strong argument against (C) is that this currently has no > parallel with how scalars are handled in PHP currently. It does not need to have a parallel. PHP as a rule is a type flexible language, my intention is not to change that, simply provide developers with yet another tool they can use to make their life easier and not break anything for people who already use PHP and don't want/need type hinting. The way current internal functions handle input should not change, since doing so will break nearly all existing code. We can provide means for authors as Hannes had pointed our earlier, of new extensions and if we choose to allow it internal methods/functions to have script type hints, but IMHO that only makes sense for future code. > - An argument for (H)/(S) is that the manual has been written in this > style, using this syntax. Manual has nothing to do with this, manual describes native(!!) PHP functions that should not implement type hints unless we as a team all decide to make PHP type strict, which I don't think is such a good idea. > - The (C) crowd suggested numeric and scalar to the (H) crowd, but I > dont think they were impressed. If you don't use numeric type for native PHP functions you will break lots of existing code. Remember the goal of this excursive is not to change the nature of PHP, but rather provide a non-destructive feature for people who see the benefit in type hinting within their own code. > - I dont think there is a strong case for a strongly typed bool. If function returns -1 on error bool cast will convert it to true, which may not be intent. Look guys, I have been using type hints for quite a long time in PHP, something I doubt most developers here can say. It does not mean people should agree with me or implies that what I say is right, but give the following a bit of consideration before listing your objects. 1) Strict type hinting helps to solve bugs, both the ones made out of careless/missing validation as well as subtle logic bugs that often take hours to resolve. I can tell you that within a week of implementing type hints we've been able to identify 30-40 bugs within a period of day. Many of which would not have been detected with "flexible" type hints that Paul is suggesting here is one example: A developer was doing "select * from table" and then using PDO fetchColumn(), on the dev environment table structure was such as the 1st column was a numeric primary key and all worked well. However, in production the order of columns was different and the returned value was actually a login name (varchar), since they happened to be numeric in nature code worked but operated on the wrong ids. It was a very subtle bug that strict type hinting identified instantly and probably saved at least hour's worth of code review. 2) Type hinting will not create a mess of cast to the right types in the code as Stas had suggested, in close to a million lines of PHP code we have, I've been able to find less then 1000 (just did a grep) instances of casts. There is a good reason for that once you get out of the input processing stage you typically (aside from __toString()) have the data in the right type. The code also includes bits from PEAR and external libs like fpdf and guess what those have no type hints and they work along side with type hinted code without any issues. Why? Well, when developers intend to return an int or a float or a boolean, they rarely convert to a string just because they can. 3) Lets not forget that PHP has always been about giving as many tools as possible to our users to help them solve various problems. When I decided to post this patch on this list, thanks largely to encouragement of fellow developers, I've also thrown it on my blog to see what users of PHP think and see if perhaps my specific use case is not applicable in common situations. Of all the replies I see no objection so far and the only complaint (funnily enough) is about existence of IS_NUMERIC. I do not wish to start a flame war or arrive at a wishy washy compromise that does not provide a solid solution. If the majority disagrees with the idea, that's perfectly fine, no harm no foul, I'll keep patching my PHP locally and if I have time maintain a type hinting patch outside of "stock php" for people to use. But please, don't reject this idea because you personally don't see yourself using it or because you want to avoid having to work in a future with a library/framework that is strict about its input or some far fetched idea that it will change the very nature of PHP. Ilia --- ## #44621 — Stanislav Malyshev — 2009-07-02T07:28:33+00:00 URL: https://externals.io/message/44619#44621 · In reply to: #44620 Hi! > 2) Type hinting will not create a mess of cast to the right types in the > code as Stas had suggested, in close to a million lines of PHP code we > have, I've been able to find less then 1000 (just did a grep) instances > of casts. There is a good reason for that once you get out of the input > processing stage you typically (aside from __toString()) have the data > in the right type. The code also includes bits from PEAR and external The problem here is that if you want to write a robust code that wouldn't randomly fail at runtime "typically" isn't good enough - since wrong type is supposed to be a fatal error (which one could not handle in the typehinted library code since it happens on the client side before your code takes control), you would want to ensure that would never happen when you call a typedhinted function. And there's only two ways to do it - either make absolutely all functions and variables that interact with typehinted functions to be strict-typed (which we don't plan do) or do casts on each call to hinted function. I do not see how anything else could produce robust code provided that type mismatch is a fatal error and variables can not carry type. > "stock php" for people to use. But please, don't reject this idea > because you personally don't see yourself using it or because you want Being a C programmer for... hmm... about 20 years now I think I don't have too much problem with strictly typed languages :) I just think doing it in PHP the way you want to do it is going to produce a lot of issues that people tend to under-appreciate when they cheer the new cool feature. Also, looking at the patch I think it doesn't cover the matter of inheriting the typehinted methods - i.e. if there's a typehinted method, could I override it with non-typehinted version or vice versa? What about typehinted interfaces? -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #44624 — Paul Biggar — 2009-07-02T08:21:13+00:00 URL: https://externals.io/message/44619#44624 · In reply to: #44621 > Also, looking at the patch I think it doesn't cover the matter of inheriting > the typehinted methods - i.e. if there's a typehinted method, could I > override it with non-typehinted version or vice versa? What about typehinted > interfaces? I don't think we need to worry about this. Consider it to be the same as default values. So yes, yes, allowed but dont do anything since those functions are never called. Paul > -- > Stanislav Malyshev, Zend Software Architect > stas@zend.com   http://www.zend.com/ > (408)253-8829   MSN: stas@zend.com > > -- > > > > -- Paul Biggar paul.biggar@gmail.com --- ## #44625 — Stanislav Malyshev — 2009-07-02T08:27:24+00:00 URL: https://externals.io/message/44619#44625 · In reply to: #44624 Hi! > I don't think we need to worry about this. Consider it to be the same > as default values. So yes, yes, allowed but dont do anything since > those functions are never called. There is a functionality handling default values (or, more precisely, optional arguments) with inheritance, etc. And it is doing something - if you declare interface as foo(int $a) and implement it as foo(string $a) there may be a lot of WTF happening. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #44626 — Paul Biggar — 2009-07-02T08:42:07+00:00 URL: https://externals.io/message/44619#44626 · In reply to: #44625 > There is a functionality handling default values (or, more precisely, > optional arguments) with inheritance, etc. Are optional argument specifications inherited? I did not think they were, but its not clear if you are saying they are. My understanding of PHP's optional arguments is that they only apply to a function once it is called. > And it is doing something - if > you declare interface as foo(int $a) and implement it as foo(string $a) > there may be a lot of WTF happening. I mean that it is never called, therefore the type hints are not checked, and this is fine. Paul -- Paul Biggar paul.biggar@gmail.com --- ## #44627 — Paul Biggar — 2009-07-02T08:45:43+00:00 URL: https://externals.io/message/44619#44627 · In reply to: #44620 > 1) Strict type hinting helps to solve bugs, both the ones made out of > careless/missing validation as well as subtle logic bugs that often take > hours to resolve. I can tell you that within a week of implementing type > hints we've been able to identify 30-40 bugs within a period of day. Many of > which would not have been detected with "flexible" type hints that Paul is > suggesting here is one example: I think you might not have read what I suggested (it is different than the one I emailed to you privately). What you want is fully supported. If you must be passed an int, use the +int hint. > type. The code also includes bits from PEAR and external libs like fpdf and > guess what those have no type hints and they work along side with type > hinted code without any issues. It is instructive that PEAR could not use your proposed hints. The "flexible" system would work fine though. > situations. Of all the replies I see no objection so far and the only > complaint (funnily enough) is about existence of IS_NUMERIC. Yes. Nobody wants numeric. It doesnt hint at anything. > I do not wish to start a flame war or arrive at a wishy washy compromise > that does not provide a solid solution. If the majority disagrees with the I think my "flexible" system is not a wishy washy compromise (the one I sent you by private email was). I think rather it has all the advantages you want, all the advantages I want, and even supports what Stas wants. > to work in a future with a library/framework that is strict about its input > or some far fetched idea that it will change the very nature of PHP. I don't think we are worried about it changing PHP, or about libraries using strict type hints. We are worried that libraries will use no hints, because the ones on offer are not useful to them. Please, take a read over my full proposal. I think you'll find it that it supports everyone's features without compromise. Thanks, Paul -- Paul Biggar paul.biggar@gmail.com --- ## #44628 — Lukas Kahwe Smith — 2009-07-02T08:56:55+00:00 URL: https://externals.io/message/44619#44628 · In reply to: #44627 > > […] > > I don't think we are worried about it changing PHP, or about libraries > using strict type hints. We are worried that libraries will use no > hints, because the ones on offer are not useful to them. I think he is replying to me here. I am worried that with Ilia's proposal, people will strictly type everything, even where weakly typed would suffice. The reason being that developers are lazy. With these type "hints" (they are not actually hints, but "checks" as you already made clear), they can very easily move the burden of type juggeling explicitly to the user of their code. At least in my world, I use a lot of 3rd party libraries, which will then likely become essentially strictly typed. While strictly typing can prevent bugs and all sorts of good stuff, we should be more hesitant when it comes to giving people tools that make it easy (encourage) to turn a core principle of PHP upside down. I know that "numeric" was a concession to people with my concern from the last discussion. But it doesnt cover all the bases of types. In that vain Paul's proposal does indeed provide a syntax that at least enables both approaches. More importantly it proposes a syntax that requires the same number of characters for both approaches. You might laugh at this comment, but I believe that the overuse of "private" that I am seeing has a lot to do with the fact that its shorter than "protected". I have not really made up my mind about Paul's proposal, but I just wanted to make the above points. regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #44635 — Giorgio Sironi — 2009-07-02T11:33:09+00:00 URL: https://externals.io/message/44619#44635 · In reply to: #44621 I'm an advocate for introducing optional type hinting as I write many assert('is_*($foo)') a day. > And there's only two ways to do it - either make absolutely all functions > and variables that interact with typehinted functions to be strict-typed > (which we don't plan do) or do casts on each call to hinted function. I do > not see how anything else could produce robust code provided that type > mismatch is a fatal error and variables can not carry type. In an application not all layers have to deal with arbitrary parameters, only the layer with user input does. Do I write a (Traversable) cast before passing an object to foreach()? No, because the object is not user input. My application will parse POST, GET, COOKIE parameters in layer 1 and call the underlying layer 2 with the right data type; down from the layer 2 to 4, 5, 10 layer I can use type hinting. Type hints became part of the contract of layer N: if there is a runtime error the problem is in layer N-1 not respecting the contract. function generate_numbers(int $maximum) { return ..... } function presentation_layer_display_numbers($input) { if (isset($input['max']) and is_numeric($input['max'])) { foreach (generate_numbers($input['max']) as $i) { echo "

$i

"; } } else { echo $formCodeWithHighlightedErrors; } } presentation_layer_display_numbers($_POST); Validating input it's something we should already do, but the other parts of the code can use type hinting. If I really pass a type that is not right to generate_numbers(), it will be a very bad thing because the function will not know how to recover; and it should not do: it's a job for the top layer. Also, looking at the patch I think it doesn't cover the matter of inheriting > the typehinted methods - i.e. if there's a typehinted method, could I > override it with non-typehinted version or vice versa? What about typehinted > interfaces? For the Liskov Substitution Principle if B extends A you should be able to call B as if it were A. So typehinted methods should be overriden respecting the typehint to allow polymorphism. interface Calculator { public function sum(int $a, int $b); } class ScientificCalculator { public function sum(int $a, int $b); } class BrokenCalculator { public function sum(int $a, string $b); // some error is thrown } class AnotherBrokenCalculator { public function sum(int $a, $b); // some error is thrown } -- Giorgio Sironi Piccolo Principe & Ossigeno Scripter http://ossigeno.sourceforge.net --- ## #44640 — Ilia Alshanetsky — 2009-07-02T12:42:37+00:00 URL: https://externals.io/message/44619#44640 · In reply to: #44621 > Hi! > > > […] > > The problem here is that if you want to write a robust code that > wouldn't randomly fail at runtime "typically" isn't good enough If it fails it means some funciton did not return the expected value and that's a problem, not something that should be ignored if you decided (if you don't want to use, then things remain as they are) to use type hinting. > - since wrong type is supposed to be a fatal error (which one could > not handle in the typehinted library code since it happens on the > client side before your code takes control), you would want to > ensure that would never happen when you call a typedhinted function. > And there's only two ways to do it - either make absolutely all > functions and variables that interact with typehinted functions to > be strict-typed (which we don't plan do) or do casts on each call to > hinted function. I do not see how anything else could produce robust > code provided that type mismatch is a fatal error and variables can > not carry type. > > > […] > > Being a C programmer for... hmm... about 20 years now I think I > don't have too much problem with strictly typed languages :) I just > think doing it in PHP the way you want to do it is going to produce > a lot of issues that people tend to under-appreciate when they cheer > the new cool feature. > > Also, looking at the patch I think it doesn't cover the matter of > inheriting the typehinted methods - i.e. if there's a typehinted > method, could I override it with non-typehinted version or vice > versa? What about typehinted interfaces? Which is fine, because some people can use that functionality to overload methods they don't want to be type hinted from external libs the may be using. --- ## #44641 — Ilia Alshanetsky — 2009-07-02T12:43:43+00:00 URL: https://externals.io/message/44619#44641 · In reply to: #44627 > > > > […] > > I think you might not have read what I suggested (it is different than > the one I emailed to you privately). What you want is fully supported. > If you must be passed an int, use the +int hint. I'd rather use -int, then +int and make people who want loose typing do the extra bit, because native typing should be strict. --- ## #44642 — Paul Biggar — 2009-07-02T12:53:01+00:00 URL: https://externals.io/message/44619#44642 · In reply to: #44641 > > > > […] > > I'd rather use -int, then +int and make people who want loose typing do the > extra bit, because native typing should be strict. I think everyone wants their favourite to be default. I was eager to have the typing that's currently in the manual be the default, since that's what people are used to seeing. I suggested that strong type checks use +int exactly because that's different to what's in the manual, so there would be no confusion. I'm really looking to get people to agree to the principle that we would like to be able to hint every signature without large changes to the manual, since we've been looking at it for years. Thanks, Paul -- Paul Biggar paul.biggar@gmail.com --- ## #44643 — Ilia Alshanetsky — 2009-07-02T12:53:48+00:00 URL: https://externals.io/message/44619#44643 · In reply to: #44628 > > > > > […] > > > I think he is replying to me here. I am worried that with Ilia's > proposal, people will strictly type everything, even where weakly > typed would suffice. The reason being that developers are lazy. With > these type "hints" (they are not actually hints, but "checks" as you > already made clear), they can very easily move the burden of type > juggeling explicitly to the user of their code. > > At least in my world, I use a lot of 3rd party libraries, which will > then likely become essentially strictly typed. While strictly typing > can prevent bugs and all sorts of good stuff, we should be more > hesitant when it comes to giving people tools that make it easy > (encourage) to turn a core principle of PHP upside down. First of all PHP is a tool, if some developers choose(!!) to adopt stricter practices (which I doubt will happen), then perhaps its time for the tool to change with them. As far as I know PHP is there to solve problems and make it easy to do so, not support/enforce certain programming paradigms. > I know that "numeric" was a concession to people with my concern > from the last discussion. But it doesnt cover all the bases of > types. In that vain Paul's proposal does indeed provide a syntax > that at least enables both approaches. More importantly it proposes > a syntax that requires the same number of characters for both > approaches. You might laugh at this comment, but I believe that the > overuse of "private" that I am seeing has a lot to do with the fact > that its shorter than "protected". Paul's proposal is some part does not make sense because it allows weak type hinting, which should not be used if you need type hinting. The whole idea about type hinting is definition of strict interfaces, not loosely based one. That's just my opinion, which admittedly I feel fairly strongly about. Ilia --- ## #44644 — Ilia Alshanetsky — 2009-07-02T13:02:18+00:00 URL: https://externals.io/message/44619#44644 · In reply to: #44642 Personally, I am uncertain about +int or -int in general, IMO that compromise will eventually be identical to numeric an cause endless confusion for the users between (+/-)int and int. The reason I used a completely different name is to prevent confusion. > > > […] > > I think everyone wants their favourite to be default. I was eager to > have the typing that's currently in the manual be the default, since > that's what people are used to seeing. I suggested that strong type > checks use +int exactly because that's different to what's in the > manual, so there would be no confusion. > > I'm really looking to get people to agree to the principle that we > would like to be able to hint every signature without large changes to > the manual, since we've been looking at it for years. > > > > Thanks, > Paul > > > > > -- > Paul Biggar > paul.biggar@gmail.com --- ## #44646 — Lukas Kahwe Smith — 2009-07-02T13:04:38+00:00 URL: https://externals.io/message/44619#44646 · In reply to: #44644 > Personally, I am uncertain about +int or -int in general, IMO that > compromise will eventually be identical to numeric an cause endless > confusion for the users between (+/-)int and int. The reason I used > a completely different name is to prevent confusion. I do not see the risk for confusion as being high. Like I said, I havent made up my mind on this proposal, however for now Paul mainly asked for feedback in the general concept, not necessarily on the syntax. regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #44645 — Robert Cummings — 2009-07-02T13:04:52+00:00 URL: https://externals.io/message/44619#44645 · In reply to: #44643 Ilia Alshanetsky wrote: > Paul's proposal is some part does not make sense because it allows > weak type hinting, which should not be used if you need type hinting. > The whole idea about type hinting is definition of strict interfaces, > not loosely based one. That's just my opinion, which admittedly I feel > fairly strongly about. It's a hint, not enforcement. IMHO hinting about something is not strict, it's a suggestion. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP --- ## #44647 — Ilia Alshanetsky — 2009-07-02T13:04:52+00:00 URL: https://externals.io/message/44619#44647 · In reply to: #44645 > Ilia Alshanetsky wrote: > > > […] > > It's a hint, not enforcement. IMHO hinting about something is not > strict, it's a suggestion. Have you using existing array or class type hinting? --- ## #44651 — Robert Cummings — 2009-07-02T13:23:08+00:00 URL: https://externals.io/message/44619#44651 · In reply to: #44647 Ilia Alshanetsky wrote: > > > > […] > > Have you using existing array or class type hinting? I have, and IMHO it makes more sense for strict checking (though not too strict since super classes make sense) when objects are being passed. But in the case of primitive datatypes where coercion between types is well established and understood, I think it should be a warning. PHP knows how to convert the string '1' to integer. It knows how to convert 0 to boolean false. These were established many years ago. On the other hand PHP does not know how to coerce (in a sensible way) class FreakyDeaky to class GobbletyGoot. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP --- ## #44648 — Ilia Alshanetsky — 2009-07-02T13:29:20+00:00 URL: https://externals.io/message/44619#44648 · In reply to: #44651 > Ilia Alshanetsky wrote: > > […] > > I have, and IMHO it makes more sense for strict checking (though not > too strict since super classes make sense) when objects are being > passed. But in the case of primitive datatypes where coercion > between types is well established and understood, I think it should > be a warning. PHP knows how to convert the string '1' to integer. It > knows how to convert 0 to boolean false. These were established many > years ago. On the other hand PHP does not know how to coerce (in a > sensible way) class FreakyDeaky to class GobbletyGoot. It is not about what PHP can convert, in the past and if you use old function parameter parsing api PHP will even convert arrays to stirngs. Its about delivering to the function/method exactly what it wants and not a close facsimile thereof. --- ## #44650 — Robert Cummings — 2009-07-02T13:45:32+00:00 URL: https://externals.io/message/44619#44650 · In reply to: #44648 Ilia Alshanetsky wrote: > > > > […] > > It is not about what PHP can convert, in the past and if you use old > function parameter parsing api PHP will even convert arrays to > strings. Its about delivering to the function/method exactly what it > wants and not a close facsimile thereof. That's why I said, instead of E_RECOVERABLE it should be an `E_WARNING` with type coercion to what the hint requested. The function gets what it wants, and the developer gets a warning that it wasn't quite what it expected. Run time code doesn't just die because I've upgraded an application and missed a single API call update to comply with primitive type hinting. That's annoying in a production environment, and since it's run-time fail, it's not necessarily easy to catch all the issues. There *will* be production systems dying due to missed updates. There's the suggestion to capture the E_RECOVERABLE error, but that's putting the onus on developers and non-developers installing applications to have this in place, and due to the run-time nature of the problem, *everyone* would be better off putting it in place, just in case their production system goes down. Since 99% of coercions of primitive types are fine, I don't see why the majority must suffer the problem when the minority will be perfectly served by an `E_WARNING` to correct their code. You mentioned in your environment you've been using this for a while now and found problems otherwise very difficult to find. These same problems would also have been detected with an `E_WARNING` with the added value of the application not dying (or do you already have that E_RECOVERABLE handler in place). Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP --- ## #44652 — Paul Biggar — 2009-07-02T14:02:40+00:00 URL: https://externals.io/message/44619#44652 · In reply to: #44643 > Paul's proposal is some part does not make sense because it allows weak type > hinting, which should not be used if you need type hinting. The whole idea > about type hinting is definition of strict interfaces, not loosely based > one. That's just my opinion, which admittedly I feel fairly strongly about. No, the idea of type hinting is that you hint to the user about what type the interface expects. You have implemented "strong type checking" instead. I wonder that you cannot see the conflict between the term "type hinting" and "strict interfaces". I would be happier if you renamed your patch "optional strong scalar type checking", which is what it is. I have described a system that allows "strong type checking", "type hinting", and "type casting", which I think is all the use cases. Thanks, Paul -- Paul Biggar paul.biggar@gmail.com --- ## #44654 — Ilia Alshanetsky — 2009-07-02T14:17:14+00:00 URL: https://externals.io/message/44619#44654 · In reply to: #44652 > > > […] > > No, the idea of type hinting is that you hint to the user about what > type the interface expects. You have implemented "strong type > checking" instead. I wonder that you cannot see the conflict between > the term "type hinting" and "strict interfaces". I would be happier if > you renamed your patch "optional strong scalar type checking", which > is what it is. That's a fair statement I suppose. --- ## #44655 — Jonathan Bond-Caron — 2009-07-02T14:17:31+00:00 URL: https://externals.io/message/44619#44655 · In reply to: #44642 > > > […] > supported. > > […] > > I think everyone wants their favourite to be default. I was eager to > have the typing that's currently in the manual be the default, since > that's what people are used to seeing. I suggested that strong type > checks use +int exactly because that's different to what's in the > manual, so there would be no confusion. > > I'm really looking to get people to agree to the principle that we > would like to be able to hint every signature without large changes to > the manual, since we've been looking at it for years. > From userland, I'm a big fan of this proposal / agree to the principle although I'm not convinced that function($quantity) function(int $quantity) function(+int $quantity) function(-int $quantity) looks appropriate... Userland Note: The "-int" semantics confuses me, I realize it would cast null's etc... but is it really a requirement? Can it be dropped? function($quantity) function(int $quantity) paul's (S) casting function(int! $quantity) STRICT type --- seems appropriate for php, follows CSS/web style '!important' To me, strict as default doesn't seem appropriate in php. But if it does, this syntax could be interesting: function($quantity) function(int $quantity) STRICT type function(~int $quantity) paul's (S) casting Btw, really interesting discussions --- ## #44656 — Paul Biggar — 2009-07-02T14:25:39+00:00 URL: https://externals.io/message/44619#44656 · In reply to: #44655 > From userland, I'm a big fan of this proposal / agree to the principle although I'm not convinced that > > function($quantity) > function(int $quantity) > function(+int $quantity) > function(-int $quantity) > > looks appropriate... > > Userland Note: The "-int" semantics confuses me, I realize it would cast null's etc... but is it really a requirement? Can it be dropped? Yes, it looks off, doesnt it. I quite like ~int, which you suggested below, for the casting. It makes me think "this is kinda an int". > function($quantity) > function(int $quantity)  paul's (S) casting > function(int! $quantity) STRICT type  --- seems appropriate for php, follows CSS/web style '!important' Yes, I like that too. > To me, strict as default doesn't seem appropriate in php. But if it does, this syntax could be interesting: > > function($quantity) > function(int $quantity)  STRICT type > function(~int $quantity) paul's (S) casting This is also a nice, internally-consistent syntax. If you had something for (H) in your suggestions, I'd be happier. We need to cast there too. Thanks, Paul -- Paul Biggar paul.biggar@gmail.com --- ## #44659 — Lewis Wright — 2009-07-02T14:54:36+00:00 URL: https://externals.io/message/44619#44659 · In reply to: #44656 2009/7/2 Paul Biggar > On Thu, Jul 2, 2009 at 3:17 PM, Jonathan Bond-Caron > wrote: > > […] > although I'm not convinced that > > […] > null's etc... but is it really a requirement? Can it be dropped? > > Yes, it looks off, doesnt it. I quite like ~int, which you suggested > below, for the casting. It makes me think "this is kinda an int". > > > > […] > follows CSS/web style '!important' > > Yes, I like that too. > But the exclamation mark has previous use in conditionals, so it may be confused with "anything but an int" Lewis. --- Next page: https://externals.io/message/44619.md?page=2