6 ms·

To explain the slightly horrible fact that there are two modes, strict and weak with strict mode being enabled on a per file basis; people just couldn't agree o

by Danack 12y ago

To explain the slightly horrible fact that there are two modes, strict and weak with strict mode being enabled on a per file basis; people just couldn't agree on whether the types should be strict or if they should use PHP's existing coercion rules. (Or even a 3rd new set of conversion rules, but lets ignore them). Having an optional mode per file allows: People who want to write code with strict types can do so. People who want to write code with weak types can do so. People who want to write code without these new fangled types can continue to do so. All without any issues of compatibility between running code on the current version of PHP and what will be the next one, and without any compatibility issues for libraries that are solely written in one mode, being used in applications that are written in the other mode. \o/ To be honest, I'm completely in the strict camp - but it's awesome that we've gotten a solution that should allow everyone to use the mode they want, without splitting the PHP ecosystem.

TazeTSchnitzel 12y ago
The big benefit is you don't end up with "weakly-typed", "strongly-typed" and "untyped" APIs. There are just "typed" and "untyped" ones, and you can choose the behaviour that suits you best.
ars 12y ago
> To be honest, I'm completely in the strict camp Can you explain why? Are you using PHP in a web context? Because everything from the web is a string. So wouldn't it make the most sense to let the functions using the web data coerce to integer, and just work? How does putting (int) before the arguments to function help anything? I actually liked Ze'ev's proposal because it let you be weak while making sure you did not coerce obviously bad data. Anyway, as a member of the strong camp, can you explain?
- bad_user 12y ago
  > Because everything from the web is a string. I would start by saying that everything, regardless of domain, is just a stream of bits. Which is completely useless, just like your assertion. And I know what you meant, but you're also wrong. A JSON object is only a string before being interpreted. An x-www-form-urlencoded is actually a map in which values can be arrays instead of primitives. Such forms often correspond to domain models with a clear definition. There's also no such thing as "obviously bad data". All data is good in the proper context, therefore automatic conversions that try to make this distinction do not make sense. I don't necessarily know how PHP behaves, but in another popular language there's a world of difference between "077" and "77". There's also a world of difference between integer, floating point and fixed point and the details are never irrelevant.
  - ars 12y ago
    > therefore automatic conversions that try to make this distinction do not make sense. You have to convert it somewhere. I don't see how the caller converting it is any better than the recipient doing it. Having the caller do it seems quite pointless when the recipient is anyway doing it. Your answer about how everything is bits was quite useless since you completely missed the point. Your input is a string, you have to convert it someplace. Weak mode has the recipient do it. Strict mode you have to do it yourself, and then the recipient double checks. I see no value in the second option - the actual conversion in both cases is identical. But Danack disagrees, so I asked him to explain. Your answer was not helpful at all.
    - bad_user 12y ago
      @ars, you completely missed my point. Lets go over it again. Tell me how should the following things convert: 77 077 77.0
      - ars 12y ago
        I GOT your point. I don't care about your point because it is not the question I am asking. Why are you answering something I did not ask? I am asking why does Danack prefer strict mode. There is absolutely nothing in my question that cares about the specific details how you convert bits to types, other than that you do. My question is entirely about WHO does the conversion. NOT about the conversion itself. (Oh, and the thing about bad-data has a defined meaning that went over your head because you are not familiar with the debate here. In this context bad-data means data loss on conversion. So "1" to 1 is fine, but "1 a" to 1 is not.)
        bad_user 12y ago
        The conversion itself is very relevant because you cannot establish a default conversion that should happen, therefore the conversions should be explicit, answering the WHO. This is why I asked you about what should the conversion produce in those examples. And also in the conversion from "1.1" to 1.1 there is loss of information, because the two representations are not isomorphic. Care to guess why?
- codygman 12y ago
  > Because everything from the web is a string. Do you consider JSON a string? Would you manipulate it as a string or use a JSON parser? > How does putting (int) before the arguments to function help anything? It throws an error in case you receive bad input, and as we all know you will receive bad input.
  - ars 12y ago
    You get json from the browser? Of course I manipulate the data - that's exactly what weak mode does, convert the strings into integers. I just don't see how doing the conversion myself manually helps anything. > It throws an error in case you receive bad input, and as we all know you will receive bad input. It does no such thing. (int) will simply turn bad input into a zero.
    - likeclockwork 12y ago
      > You get json from the browser? Yes.
      - ars 12y ago
        Really? All the pages you program with forms, and links and whatever are sending you json? I have no doubt you CAN do it, but most of the time you don't. And since most of the time you are dealing with strings my question stands: Why do the conversion manually instead of letting the nice new feature do it for you.
        slight 12y ago
        You've heard of JavaScript I presume?
        ars 12y ago
        Even AJAX sites do not typically send all data back as JSON. Most of the time they use normal form-urlencoded data. If you did send everything as JSON you would be bypassing everything PHP does with form/url data to make things easier for you (for example arrays). That doesn't seem like a good engineering tradeoff.
- pserwylo 12y ago
  > Can you explain why? Over the years, we have refactored our PHP code base to something which is much more bug proof, and a lot of it is because we demand certain types to be passed to types. Currently we use doc types (for which the IDE helps us heaps) and type hinting for objects being passed as arguments. For a given process (e.g. form submission) there will nevertheless be an entry point where strings from the web are passed in. But if you can minimize that area as much as possible, beyond that one place (a function or class) which understands the mapping from incoming string types to PHP types, you end up with a code base which behaves mostly like a statically type language. This has reduced a huge subset of bugs which are caused by unexpected input being passed to a function. Having the language itself tell you when you made an error statically while writing is much better than having to wait until runtime. A similar argument would stand for why we moved from dynamically created strings sent to the database, towards a database abstraction layer where we pick up syntax errors at time of writing.
- Danack 12y ago
  > Can you explain why? Hopefully. > How does putting (int) before the arguments to function help anything? It wouldn't. Anyone who is casting from an unknown type to an int by using just `(int)` is doing something wrong in my opinion. Even in web-based applications there are at least two layers of code: i) One where the type of the values are unknown and they are represented as strings. ii) One where the types of the values are known. At the boundary between these two layers you should have code that inspects the strings that represent the input values, check that they are acceptable, and convert them to the desired type. If the input values cannot be converted to the desired type, the code needs to give an error that is both specific to the type of error so that a computer can understand it, as well as provide a human understandable explanation of why the conversion was not allowed. The reason why I want strong types is that I never, ever want to blindly cast from one type to another. The decision about how to convert from one type to another, should always be made at a boundary between areas of the application where types are known, and the areas where the types are unknown. I always want to be forced to make that decision in the right place, using code that gives useful errors and messages, rather than having the value coerced into the desired type. tl;dr I won't use (int) to cast, I will use something like the code below. cheers Dan function validateOrderAmount($value) : int { $count = preg_match("/[^0-9]*/", $value); if ($count) { throw new InvalidOrderAmount("Order amount must contain only digits."); } $value = intval($value); if ($value < 1) { throw new InvalidOrderAmount("Order amount must be one or more."); } if ($value >= MAX_ORDER_AMOUNT) { throw new InvalidOrderAmount("You can only order ".MAX_ORDER_AMOUNT." at a time."); } return $value; } function processOrderRequest() { $orderAmount = validateOrderAmount($_REQUEST['orderAmount']); //Yay, our IDE/static code analyzer can tell that $amount is an int if the code reached here. placeOrder($orderAmount); }
  - ars 12y ago
    Thank you for the reply! (The rest of the replies to me got seriously derailed....) So from your code it looks like the only benefit of strict mode is in case you forget to do the validation/conversion it will warn you? I guess that's reasonable. Is there any other benefit? To me it seems that Ze'ev's proposal would be even better for you - it does the equivalent of the validation and conversion automatically including with an error if it doesn't validate. You wrote "let's ignore that", but it really seems like to best of all worlds to me. Any idea why it was rejected so badly? Is it because the coercion rules are different from the rest of PHP?

by Danack 12y ago

TazeTSchnitzel 12y ago

The big benefit is you don't end up with "weakly-typed", "strongly-typed" and "untyped" APIs. There are just "typed" and "untyped" ones, and you can choose the behaviour that suits you best.

ars 12y ago

> To be honest, I'm completely in the strict camp Can you explain why? Are you using PHP in a web context? Because everything from the web is a string. So wouldn't it make the most sense to let the functions using the web data coerce to integer, and just work? How does putting (int) before the arguments to function help anything? I actually liked Ze'ev's proposal because it let you be weak while making sure you did not coerce obviously bad data. Anyway, as a member of the strong camp, can you explain?

bad_user 12y ago
> Because everything from the web is a string. I would start by saying that everything, regardless of domain, is just a stream of bits. Which is completely useless, just like your assertion. And I know what you meant, but you're also wrong. A JSON object is only a string before being interpreted. An x-www-form-urlencoded is actually a map in which values can be arrays instead of primitives. Such forms often correspond to domain models with a clear definition. There's also no such thing as "obviously bad data". All data is good in the proper context, therefore automatic conversions that try to make this distinction do not make sense. I don't necessarily know how PHP behaves, but in another popular language there's a world of difference between "077" and "77". There's also a world of difference between integer, floating point and fixed point and the details are never irrelevant.
- ars 12y ago
  > therefore automatic conversions that try to make this distinction do not make sense. You have to convert it somewhere. I don't see how the caller converting it is any better than the recipient doing it. Having the caller do it seems quite pointless when the recipient is anyway doing it. Your answer about how everything is bits was quite useless since you completely missed the point. Your input is a string, you have to convert it someplace. Weak mode has the recipient do it. Strict mode you have to do it yourself, and then the recipient double checks. I see no value in the second option - the actual conversion in both cases is identical. But Danack disagrees, so I asked him to explain. Your answer was not helpful at all.
  - bad_user 12y ago
    @ars, you completely missed my point. Lets go over it again. Tell me how should the following things convert: 77 077 77.0
    - ars 12y ago
      I GOT your point. I don't care about your point because it is not the question I am asking. Why are you answering something I did not ask? I am asking why does Danack prefer strict mode. There is absolutely nothing in my question that cares about the specific details how you convert bits to types, other than that you do. My question is entirely about WHO does the conversion. NOT about the conversion itself. (Oh, and the thing about bad-data has a defined meaning that went over your head because you are not familiar with the debate here. In this context bad-data means data loss on conversion. So "1" to 1 is fine, but "1 a" to 1 is not.)
      - bad_user 12y ago
        The conversion itself is very relevant because you cannot establish a default conversion that should happen, therefore the conversions should be explicit, answering the WHO. This is why I asked you about what should the conversion produce in those examples. And also in the conversion from "1.1" to 1.1 there is loss of information, because the two representations are not isomorphic. Care to guess why?
codygman 12y ago
> Because everything from the web is a string. Do you consider JSON a string? Would you manipulate it as a string or use a JSON parser? > How does putting (int) before the arguments to function help anything? It throws an error in case you receive bad input, and as we all know you will receive bad input.
- ars 12y ago
  You get json from the browser? Of course I manipulate the data - that's exactly what weak mode does, convert the strings into integers. I just don't see how doing the conversion myself manually helps anything. > It throws an error in case you receive bad input, and as we all know you will receive bad input. It does no such thing. (int) will simply turn bad input into a zero.
  - likeclockwork 12y ago
    > You get json from the browser? Yes.
    - ars 12y ago
      Really? All the pages you program with forms, and links and whatever are sending you json? I have no doubt you CAN do it, but most of the time you don't. And since most of the time you are dealing with strings my question stands: Why do the conversion manually instead of letting the nice new feature do it for you.
      - slight 12y ago
        You've heard of JavaScript I presume?
        ars 12y ago
        Even AJAX sites do not typically send all data back as JSON. Most of the time they use normal form-urlencoded data. If you did send everything as JSON you would be bypassing everything PHP does with form/url data to make things easier for you (for example arrays). That doesn't seem like a good engineering tradeoff.
pserwylo 12y ago
> Can you explain why? Over the years, we have refactored our PHP code base to something which is much more bug proof, and a lot of it is because we demand certain types to be passed to types. Currently we use doc types (for which the IDE helps us heaps) and type hinting for objects being passed as arguments. For a given process (e.g. form submission) there will nevertheless be an entry point where strings from the web are passed in. But if you can minimize that area as much as possible, beyond that one place (a function or class) which understands the mapping from incoming string types to PHP types, you end up with a code base which behaves mostly like a statically type language. This has reduced a huge subset of bugs which are caused by unexpected input being passed to a function. Having the language itself tell you when you made an error statically while writing is much better than having to wait until runtime. A similar argument would stand for why we moved from dynamically created strings sent to the database, towards a database abstraction layer where we pick up syntax errors at time of writing.
Danack 12y ago
> Can you explain why? Hopefully. > How does putting (int) before the arguments to function help anything? It wouldn't. Anyone who is casting from an unknown type to an int by using just `(int)` is doing something wrong in my opinion. Even in web-based applications there are at least two layers of code: i) One where the type of the values are unknown and they are represented as strings. ii) One where the types of the values are known. At the boundary between these two layers you should have code that inspects the strings that represent the input values, check that they are acceptable, and convert them to the desired type. If the input values cannot be converted to the desired type, the code needs to give an error that is both specific to the type of error so that a computer can understand it, as well as provide a human understandable explanation of why the conversion was not allowed. The reason why I want strong types is that I never, ever want to blindly cast from one type to another. The decision about how to convert from one type to another, should always be made at a boundary between areas of the application where types are known, and the areas where the types are unknown. I always want to be forced to make that decision in the right place, using code that gives useful errors and messages, rather than having the value coerced into the desired type. tl;dr I won't use (int) to cast, I will use something like the code below. cheers Dan function validateOrderAmount($value) : int { $count = preg_match("/[^0-9]*/", $value); if ($count) { throw new InvalidOrderAmount("Order amount must contain only digits."); } $value = intval($value); if ($value < 1) { throw new InvalidOrderAmount("Order amount must be one or more."); } if ($value >= MAX_ORDER_AMOUNT) { throw new InvalidOrderAmount("You can only order ".MAX_ORDER_AMOUNT." at a time."); } return $value; } function processOrderRequest() { $orderAmount = validateOrderAmount($_REQUEST['orderAmount']); //Yay, our IDE/static code analyzer can tell that $amount is an int if the code reached here. placeOrder($orderAmount); }
- ars 12y ago
  Thank you for the reply! (The rest of the replies to me got seriously derailed....) So from your code it looks like the only benefit of strict mode is in case you forget to do the validation/conversion it will warn you? I guess that's reasonable. Is there any other benefit? To me it seems that Ze'ev's proposal would be even better for you - it does the equivalent of the validation and conversion automatically including with an error if it doesn't validate. You wrote "let's ignore that", but it really seems like to best of all worlds to me. Any idea why it was rejected so badly? Is it because the coercion rules are different from the rest of PHP?