7 ms·

... Note the syntax isn’t the usual double pipe || operator that we associate with or, rather a single pipe | character ... ... PHP 7.1 introduces visibility m

... Note the syntax isn’t the usual double pipe || operator that we associate with or, rather a single pipe | character ... ... PHP 7.1 introduces visibility modifiers to constants ... ... With PHP 7.1 it is now possible to specify that a function has a void return type, i.e. it performs an action but does not return anything ... ... Example four contains numeric values, so everything else is stripped out, and the sum of those are used to calculate the total of 10. But it would still be nice to see a warning, as this may not be intended behaviour ... Good to see PHP continues to introduce new inconsistencies while striving to break existing code by fixing old ones. Best of both worlds! edit: OK this was uncharitable and technically some of them are not inconsistencies, just things I thought were weird. I know PHP is widely used and considered useful and will stay with us forever. But I found those snippets interesting.

moonshinefe 10y ago
Which inconsistencies are those? Functions that return; or don't return at all already return null in PHP.
- codeulike 10y ago
  I suppose its not an inconsistency as such, but I included it because I thought it was funny.
naranha 10y ago
I wonder why PHP includes more and more type checks and visibility features, when all those checks are performed at runtime. What good does it do when your code suddenly throws a fatal error at runtime because you did not respect the type specification. I mean, I get that type checks are useful for IDEs, but enforcing these rules at runtime using fatal errors just does not make any sense to me.
- TazeTSchnitzel 10y ago
  If they're not enforced at runtime, then they're unsound if you have typed code calling untyped code. And as the maker of the sibling comment notes, runtime type checks still catch errors earlier than no type checks. Moreover, having these declarations actually be part of the language, even if the interpreter itself cannot enforce them ahead-of-time, means tooling can be built around it, and we can use them for optimisations in the VM (which PHP 7.1 does: we elide type checks on certain arithmetic operations for operands of known types). If you want to ensure type safety before the program actually runs, you can of course let your IDE or static analyser check that for you.
  - naranha 10y ago
    > If they're not enforced at runtime, then they're unsound if you have typed code calling untyped code. I think types specifications in interpreted (not compiled) languages should be only hints (for IDEs, code analyzers and JIT compilation etc.). This type checking for every method probably also adds some overhead does it not? EDIT: correction
    - TazeTSchnitzel 10y ago
      Yes, it adds overhead. But it means the type declaration can actually be relied upon: the code inside the function always gets the type it wants, the optimiser can elide type checks safely, and humans and computers reading the code don't have to worry about the type declaration being a lie. Unenforced type hints don't give these guarantees. They have no requirement to be accurate because the runtime won't enforce them, so they're essentially documentation, not code. They can't be safely relied upon by the optimiser because they're unenforced. The code inside the function body can break at runtime if given the wrong type, so if having a specific type is particularly important, you have to add manual type checks or coercions yourself.
      - naranha 10y ago
        But these checks could also be performed by a code analyzer/compiler, removing this burden from the runtime. (Performing the checks at runtime, means the code is only checked when it is executed, which could be at any random time.)
- vertex-four 10y ago
  If you're using type signatures, the alternative is probably going to be that your program crashes at a later time. "Foo is not a Bar" is a better error message than "$foo->xyz() isn't a function", and this happens much closer to the point where you've messed up.
  - naranha 10y ago
    I disagree. I think that this type of "late type binding" is actually an advantage of dynamically typed languages. That way it does not matter if you pass a map/array/dictionary or an instance of a class as long as the properties are the same.
    - chrisseaton 10y ago
      I think one problem is when your object quacks like a duck, but the quack doesn't mean what you think it means. Having methods that just have the right names is a pretty weak assurance, isn't it?
    - zodiac 10y ago
      The type hinting is optional, so if you want "late type binding" you can just omit the type hints.
    - spdionis 10y ago
      "Fail Fast" is a pretty popular best-practice and failing immediately on a mismatched type hint is in line with that.
    - vertex-four 10y ago
      Then... don't specify that you want a specific type?
- SilkRoadie 10y ago
  PHPDoc is supported by most IDE's. Using this you can specify parameter types without using the actual type system. Visibility and typing features are good. Visibility helps to design and write better code. The typing features are also welcomed in my view. I would rather a request completely fails because a variable is the wrong type rather than PHP's type coercion leading to an unexpected result with no errors or warnings. That said, I use PHP for my day job. I see no reason to start new projects in it. I never use it in my side projects. Introduction of the single pipe operator to represent OR instead of a double pipe operator is baffling in my opinion. 7.1 does more work to improve consistency and error handling which is definitely welcomed. The problem is there is much legacy crap in PHP. It only exists for web applications and there are a growing number of languages which do this better.
  - nkozyra 10y ago
    > Introduction of the single pipe operator to represent OR instead of a double pipe operator is baffling in my opinion. I kind of understand it since it's not a traditional OR operation and intends to keep and associate the matching values, but maybe something like catch (Exception $e in (Exceptions...)) would make it clearer. Either way, it's so close to feeling like an OR operation that I feel like it will be a lot of debugging when you forget this.
- greatdipper 10y ago
  >I wonder why PHP includes more and more type checks and visibility features Because they are easy to implement (function type hints, typed properties) and the php community have a collective, insatiable, perpetual hardon for features that are supposed to enhance correctness.. So the core devs are eager to propose these kinds of features. And the community is eager to accepts them without much thought.. To see how child like this mentality towards these type of features, see this comment, where a Php expert makes a big deal regarding when a user omitted mentioning the type of a value.... https://www.reddit.com/r/PHP/comments/4k2htl/ive_just_given_5_interviews_to_senior_developers/d3buk6g https://www.reddit.com/r/PHP/comments/4k2htl/ive_just_given_...
- tomschlick 10y ago
  > What good does it do when your code suddenly throws a fatal error at runtime because you did not respect the type specification. The good it does is it stops your application from possibly continuing on with buggy code. This is especially important in something like billing code. Imagine if your code was expecting an integer (bill amount) but got a string instead that via the types system evaluated to 0 or 1 instead of the real integer... In that case you might charge customers less or more than you should have and its a big deal trying to get all that fixed. Better to just throw an error which you can see in an exception handling system like Sentry and take care of the problem.
elgenie 10y ago
This hot take is both pretty uncharitable and largely incorrect. ... "catch (FooException | BarException" is new syntax that would be a include-time fatal in existing code ... "public const FOO" is new syntax that would be a include-time fatal in existing code; public is the default modifier in the language when no visibility modifier is present, so existing code functions exactly the same as before ... ": void" return type only conflicts with existing code if a class is named Void, which becomes an error for the file declaring the class ... this is vanishingly unlikely [0] and an easy grep to fix; if you're looking at some code "$var = i_return_void();", the annotation is a clear sign that the "$var =" part is obviously confused. ... " 5 + 'a string' " is nonsense code which codebases that care about warnings currently want to be aware of. [0] even the few hits for https://github.com/search?utf8=%E2%9C%93&q=%22class+Void+%22&type=Code&ref=searchresults&l=PHP https://github.com/search?utf8=%E2%9C%93&q=%22class+Void+%22... are mostly false positives.
Mithaldu 10y ago
I don't like PHP either, but that doesn't mean kneejerk reactions are excusable, and at the least on the first point you are wrong. Using | instead of || is not an inconsistency, but actually quite consistent. || is a short-cutting or comparison operator which returns the first true thing it encounters. | is a bitwise or combinator, which takes two sets of flags, and combines them into one set of flags that has all flags activated which were also active in the input sets. Semantically, | is absolutely the correct choice here. A better question would be why there's a $2 there, though i hope that's just a typo and means $e.
- bpicolo 10y ago
  Better yet, don't reinvent the world and just use commas?
  - Mithaldu 10y ago
    Commas would require changing the syntax and implementation of catch. This way exception names just become first class subjects that can be combined with an overloaded operator.
  - fredleblanc 10y ago
    Commas are used in PHP as a sequence of things, not multiple options. This single-pipe notation is already established as the further-up comments states.
    - jack9 10y ago
      > Commas are used in PHP as a sequence of things Choosing a pipe because it's easier for an obscure language feature, is not least astonishment. Commas are used for lists. The pipe is a bad choice among a nice feature.
- arenaninja 10y ago
  This is correct. PHP makes extensive use of bitwise operators for function options. For examples, see json_encode, htmlentities, filter_input, etc.

moonshinefe 10y ago

Which inconsistencies are those? Functions that return; or don't return at all already return null in PHP.

codeulike 10y ago
I suppose its not an inconsistency as such, but I included it because I thought it was funny.

naranha 10y ago

I wonder why PHP includes more and more type checks and visibility features, when all those checks are performed at runtime. What good does it do when your code suddenly throws a fatal error at runtime because you did not respect the type specification. I mean, I get that type checks are useful for IDEs, but enforcing these rules at runtime using fatal errors just does not make any sense to me.

TazeTSchnitzel 10y ago
If they're not enforced at runtime, then they're unsound if you have typed code calling untyped code. And as the maker of the sibling comment notes, runtime type checks still catch errors earlier than no type checks. Moreover, having these declarations actually be part of the language, even if the interpreter itself cannot enforce them ahead-of-time, means tooling can be built around it, and we can use them for optimisations in the VM (which PHP 7.1 does: we elide type checks on certain arithmetic operations for operands of known types). If you want to ensure type safety before the program actually runs, you can of course let your IDE or static analyser check that for you.
- naranha 10y ago
  > If they're not enforced at runtime, then they're unsound if you have typed code calling untyped code. I think types specifications in interpreted (not compiled) languages should be only hints (for IDEs, code analyzers and JIT compilation etc.). This type checking for every method probably also adds some overhead does it not? EDIT: correction
  - TazeTSchnitzel 10y ago
    Yes, it adds overhead. But it means the type declaration can actually be relied upon: the code inside the function always gets the type it wants, the optimiser can elide type checks safely, and humans and computers reading the code don't have to worry about the type declaration being a lie. Unenforced type hints don't give these guarantees. They have no requirement to be accurate because the runtime won't enforce them, so they're essentially documentation, not code. They can't be safely relied upon by the optimiser because they're unenforced. The code inside the function body can break at runtime if given the wrong type, so if having a specific type is particularly important, you have to add manual type checks or coercions yourself.
    - naranha 10y ago
      But these checks could also be performed by a code analyzer/compiler, removing this burden from the runtime. (Performing the checks at runtime, means the code is only checked when it is executed, which could be at any random time.)
vertex-four 10y ago
If you're using type signatures, the alternative is probably going to be that your program crashes at a later time. "Foo is not a Bar" is a better error message than "$foo->xyz() isn't a function", and this happens much closer to the point where you've messed up.
- naranha 10y ago
  I disagree. I think that this type of "late type binding" is actually an advantage of dynamically typed languages. That way it does not matter if you pass a map/array/dictionary or an instance of a class as long as the properties are the same.
  - chrisseaton 10y ago
    I think one problem is when your object quacks like a duck, but the quack doesn't mean what you think it means. Having methods that just have the right names is a pretty weak assurance, isn't it?
  - zodiac 10y ago
    The type hinting is optional, so if you want "late type binding" you can just omit the type hints.
  - spdionis 10y ago
    "Fail Fast" is a pretty popular best-practice and failing immediately on a mismatched type hint is in line with that.
  - vertex-four 10y ago
    Then... don't specify that you want a specific type?
SilkRoadie 10y ago
PHPDoc is supported by most IDE's. Using this you can specify parameter types without using the actual type system. Visibility and typing features are good. Visibility helps to design and write better code. The typing features are also welcomed in my view. I would rather a request completely fails because a variable is the wrong type rather than PHP's type coercion leading to an unexpected result with no errors or warnings. That said, I use PHP for my day job. I see no reason to start new projects in it. I never use it in my side projects. Introduction of the single pipe operator to represent OR instead of a double pipe operator is baffling in my opinion. 7.1 does more work to improve consistency and error handling which is definitely welcomed. The problem is there is much legacy crap in PHP. It only exists for web applications and there are a growing number of languages which do this better.
- nkozyra 10y ago
  > Introduction of the single pipe operator to represent OR instead of a double pipe operator is baffling in my opinion. I kind of understand it since it's not a traditional OR operation and intends to keep and associate the matching values, but maybe something like catch (Exception $e in (Exceptions...)) would make it clearer. Either way, it's so close to feeling like an OR operation that I feel like it will be a lot of debugging when you forget this.
greatdipper 10y ago
>I wonder why PHP includes more and more type checks and visibility features Because they are easy to implement (function type hints, typed properties) and the php community have a collective, insatiable, perpetual hardon for features that are supposed to enhance correctness.. So the core devs are eager to propose these kinds of features. And the community is eager to accepts them without much thought.. To see how child like this mentality towards these type of features, see this comment, where a Php expert makes a big deal regarding when a user omitted mentioning the type of a value.... https://www.reddit.com/r/PHP/comments/4k2htl/ive_just_given_5_interviews_to_senior_developers/d3buk6g https://www.reddit.com/r/PHP/comments/4k2htl/ive_just_given_...
tomschlick 10y ago
> What good does it do when your code suddenly throws a fatal error at runtime because you did not respect the type specification. The good it does is it stops your application from possibly continuing on with buggy code. This is especially important in something like billing code. Imagine if your code was expecting an integer (bill amount) but got a string instead that via the types system evaluated to 0 or 1 instead of the real integer... In that case you might charge customers less or more than you should have and its a big deal trying to get all that fixed. Better to just throw an error which you can see in an exception handling system like Sentry and take care of the problem.

elgenie 10y ago

This hot take is both pretty uncharitable and largely incorrect. ... "catch (FooException | BarException" is new syntax that would be a include-time fatal in existing code ... "public const FOO" is new syntax that would be a include-time fatal in existing code; public is the default modifier in the language when no visibility modifier is present, so existing code functions exactly the same as before ... ": void" return type only conflicts with existing code if a class is named Void, which becomes an error for the file declaring the class ... this is vanishingly unlikely [0] and an easy grep to fix; if you're looking at some code "$var = i_return_void();", the annotation is a clear sign that the "$var =" part is obviously confused. ... " 5 + 'a string' " is nonsense code which codebases that care about warnings currently want to be aware of. [0] even the few hits for https://github.com/search?utf8=%E2%9C%93&q=%22class+Void+%22&type=Code&ref=searchresults&l=PHP https://github.com/search?utf8=%E2%9C%93&q=%22class+Void+%22... are mostly false positives.

Mithaldu 10y ago

I don't like PHP either, but that doesn't mean kneejerk reactions are excusable, and at the least on the first point you are wrong. Using | instead of || is not an inconsistency, but actually quite consistent. || is a short-cutting or comparison operator which returns the first true thing it encounters. | is a bitwise or combinator, which takes two sets of flags, and combines them into one set of flags that has all flags activated which were also active in the input sets. Semantically, | is absolutely the correct choice here. A better question would be why there's a $2 there, though i hope that's just a typo and means $e.

bpicolo 10y ago
Better yet, don't reinvent the world and just use commas?
- Mithaldu 10y ago
  Commas would require changing the syntax and implementation of catch. This way exception names just become first class subjects that can be combined with an overloaded operator.
- fredleblanc 10y ago
  Commas are used in PHP as a sequence of things, not multiple options. This single-pipe notation is already established as the further-up comments states.
  - jack9 10y ago
    > Commas are used in PHP as a sequence of things Choosing a pipe because it's easier for an obscure language feature, is not least astonishment. Commas are used for lists. The pipe is a bad choice among a nice feature.
arenaninja 10y ago
This is correct. PHP makes extensive use of bitwise operators for function options. For examples, see json_encode, htmlentities, filter_input, etc.