4 ms·

> 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 compil

by 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.)
  - TazeTSchnitzel 10y ago
    Ahead-of-time type checking can only really work if the entire program has type declarations everywhere, and if you know what constitutes the entire program. This isn't the case for the vast majority of existing PHP code. Furthermore, PHP's dynamic features mean that there are cases where ahead-of-time checks will always be impossible. So you have to have at least some runtime checks, at the boundaries between typed and untyped code. Furthermore, doing ahead-of-time checking would require infrastructure we don't currently have for providing information to the PHP interpreter about whether or not PHP files have passed type checks. But again, most code is not fully typed, and so this doesn't provide all that many guarantees to the interpreter.
    - mcbits 10y ago
      I've seen quite a few JavaScript bugs and potential bugs exposed after adding incomplete type annotations in TypeScript, so I really don't think it's all or nothing, at least not as a general rule. I've been away from PHP too long to speculate how much it would help here.
      - TazeTSchnitzel 10y ago
        Sure, it's not all-or-nothing, type checks that aren't enforced at runtime have some benefits, I just disagree that they can provide all of them.

by naranha 10y ago

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.)
- TazeTSchnitzel 10y ago
  Ahead-of-time type checking can only really work if the entire program has type declarations everywhere, and if you know what constitutes the entire program. This isn't the case for the vast majority of existing PHP code. Furthermore, PHP's dynamic features mean that there are cases where ahead-of-time checks will always be impossible. So you have to have at least some runtime checks, at the boundaries between typed and untyped code. Furthermore, doing ahead-of-time checking would require infrastructure we don't currently have for providing information to the PHP interpreter about whether or not PHP files have passed type checks. But again, most code is not fully typed, and so this doesn't provide all that many guarantees to the interpreter.
  - mcbits 10y ago
    I've seen quite a few JavaScript bugs and potential bugs exposed after adding incomplete type annotations in TypeScript, so I really don't think it's all or nothing, at least not as a general rule. I've been away from PHP too long to speculate how much it would help here.
    - TazeTSchnitzel 10y ago
      Sure, it's not all-or-nothing, type checks that aren't enforced at runtime have some benefits, I just disagree that they can provide all of them.