3 ms·

Praise Jesus Typed properties!!

donatj 7y ago
I’m on the fence about their usefulness. There is a type check on every write, which can lead to major performance losses. Rasmus, the creator of PHP, lamented this in a recent talk. Using getters and setters already got us type checking external to the class, and is generally good OO practice. Internally I think static analysis on documented types was a good enough solution.
- derision 7y ago
  Looks like they're optional anyway so you're free to do things however you like
  - lowercased 7y ago
    isn't the system still going to have to check if a type exists or not anyway, contributing to the potential speed issue?
    - derision 7y ago
      I'm assuming the check happens at compile time (and therefore cached in the opcache, which you should be using in production anyway)
      - lowercased 7y ago
        i would think you'd still have dynamic check - trying to set a string in to an integer type would happen at runtime - you'd be checking before each set call. I'm not sure you'd be able to catch all the runtime potential issues ahead of time (but I've not kept up with php internals for awhile - perhaps someone's got a good way to do that now?)
        namibj 7y ago
        What I remember from reading master a few months ago: the zend VM can specialize ops already, trading size of the op-implementations against type-check-elision/fusion by GCC/clang. I think eliding redundant type checks at least won't be hard when confined to a single php function.
- vegannet 7y ago
  Setters and getters aren’t really object oriented. An object has behaviour, ensuring the inner workings of that object are protected is a good thing _even if_ the inner workings are only ever inner workings. There’s lots of valid and meaningful uses of this functionality.
- Cthulhu_ 7y ago
  I'd say that depends on implementation; a lot of languages will only check types on compile. If anything it's a hint for developers, something that their editor will error on if they try and do something wrong.

I’m on the fence about their usefulness. There is a type check on every write, which can lead to major performance losses. Rasmus, the creator of PHP, lamented this in a recent talk. Using getters and setters already got us type checking external to the class, and is generally good OO practice. Internally I think static analysis on documented types was a good enough solution.

derision 7y ago
Looks like they're optional anyway so you're free to do things however you like
- lowercased 7y ago
  isn't the system still going to have to check if a type exists or not anyway, contributing to the potential speed issue?
  - derision 7y ago
    I'm assuming the check happens at compile time (and therefore cached in the opcache, which you should be using in production anyway)
    - lowercased 7y ago
      i would think you'd still have dynamic check - trying to set a string in to an integer type would happen at runtime - you'd be checking before each set call. I'm not sure you'd be able to catch all the runtime potential issues ahead of time (but I've not kept up with php internals for awhile - perhaps someone's got a good way to do that now?)
      - namibj 7y ago
        What I remember from reading master a few months ago: the zend VM can specialize ops already, trading size of the op-implementations against type-check-elision/fusion by GCC/clang. I think eliding redundant type checks at least won't be hard when confined to a single php function.
vegannet 7y ago
Setters and getters aren’t really object oriented. An object has behaviour, ensuring the inner workings of that object are protected is a good thing _even if_ the inner workings are only ever inner workings. There’s lots of valid and meaningful uses of this functionality.
Cthulhu_ 7y ago
I'd say that depends on implementation; a lot of languages will only check types on compile. If anything it's a hint for developers, something that their editor will error on if they try and do something wrong.