5 ms·

New to PHP 5.4: Traits

85 points by simast 16y ago

tszming 16y ago
5.3 => closure, 5.4 => traits, PHP's revolution? Honestly, I would prefer PHP remove all the bad parts of PHP before adding new things.
- ameketa 16y ago
  At least they didn't implement them by trying to come up with every possible mixin you'd ever want to write and then define them in the global namespace. Progress?
- pilif 16y ago
  Do you know how long it took to finally get rid of PHP 4? Do you know how long web hosters (and with that most open source projects targeting a wide audience) were sticking with PHP4? Even now that there won't be any more php4 releases, there are STILL projects targeting PHP4. There are STILL webhosts only providing support for PHP4. More than 5 years after PHP5 came out All this even though most PHP4 scripts run unaltered in php5. And now you suggest to drop backwards compatibiliy to get rid of warts? How long do you think it would take before that new language will get any significant deployment? What good will all the new features be if you are not able to use them in the next 10+ years? Personally, I like to see them add features in a backwards compatible way. Knowing PHP and programming in general, I can stay away of the bad parts but still use all the new features in the foreseeable (2-3 years) future. Just have a look at python3 of you want a taste if what you were just suggesting.
  - tszming 16y ago
    I agree with you that incompatible changes by removing bad parts is definitely painful, but it makes PHP more sustainable in long term. This can happen in a more feasible way, e.g. freeze PHP5 (unlike the current situation), don't add any new stuffs; branch out a subset of PHP (removing bad parts), and continue the development there.
    - simast 16y ago
      Not sure of what kind of legacy features you would want to be removed but it's not like they are just building on top without thinking. PHP 5.4 will also drop: - safe mode - register_globals - allow_call_time_pass_reference/y2k_compliance and other legacy ini stuff - "continue 123" syntax (can be replaced with goto). As far as I recall this is done since it's barely used and if removed would allow to implement some opcode performance optimizations. Dropping some PHP 4 era syntax is obviously out of question due to already mentioned webhosting and backwards compatibility issues.
  - wazoox 16y ago
    > Even now that there won't be any more php4 releases, there are STILL projects targeting PHP4. There are STILL webhosts only providing support for PHP4. More than 5 years after PHP5 came out The fact that PHP broke many websites when going from PHP3 to PHP4, then at each PHP4 minor release is probably largely responsible for this conservatism.
  - robryan 16y ago
    Depreciating things is moving in the right direction, throwing a depreciated warning in the code. Slow but good way to change developer behaviors towards better PHP code. http://php.net/manual/en/migration53.deprecated.php http://php.net/manual/en/migration53.deprecated.php
    - bluesnowmonkey 16y ago
      Deprecating.
- leftnode 16y ago
  I love all of the new stuff coming to PHP, and frankly, I agree with you, but removing the "bad" parts would break so many applications. Standardizing things, making libraries consistent, and adding some type of strict typing would be the nicest things to do, I believe.
- RossM 16y ago
  A few of PHP's most (publicly) hated components are being removed in 5.4 (which may become 6, from what I can tell this article is lying when it says 5.4 is "around the corner") - register_globals, magic_quotes is being discussed. Even the old asp_tags setting is going. However these have no relevance to me as I haven't used them in years.
  - robryan 16y ago
    If they are going that far, it would probably be better to get rid of more in one go, rather than giving people legacy code headaches with each release.
    - philfreo 16y ago
      What else do you think they should remove?
      - robryan 16y ago
        I guess I would focus on cleanup, method names and parameter orders. I don't know enough about the internals to know if also allowing say $var = $val->substring(0, 2); could be an alias to how values are currently passed into functions.
- Nitramp 16y ago
  Honestly, I would prefer PHP remove all the bad parts of PHP before adding new things. This has already been done, and the result is called "Python" (or Ruby, or ...). SCNR. Edit: ok, I realize this was maybe a bit too snarky. But I mean it: if you remove all the somewhat strange parts from PHP, you are breaking backwards compatibility. And at that point, your users have no reason not to move to another, maybe cleaner language (e.g. Python) all together. So if you want to get a cleaner PHP while breaking backwards compatibility, you might as well just use a different language.
- xtho 16y ago
  Considering how they implemented closures, I wonder what that revolution would look like.
deleted 16y ago
[deleted]
agentultra 16y ago
I don't understand the vernacular. One of the noteworthy language additions are Traits – a brand new horizontal code reuse mechanism. Code re-use mechanism? Horizontal? I didn't realize PHP was so geometric. What an interesting concept. While traits are technically different from mixins – they are both designed to fill the same gap left by a single-parent inheritance model So let me try and get this straight: mixins fill a gap left by a single-parent inheritance model and so traits are like mixins because PHP has a single-inheritance model but traits are technically different in some way? This is getting confusing... Python, Perl, Ruby, and many languages with multiple inheritance have been using mixins for... well a long time. It's pretty straight forward. Perl5 got "roles" through Moose and Perl6 has them natively. I think they're explanations are a little more clear. (http://search.cpan.org/dist/Moose/lib/Moose/Manual/Roles.pod http://search.cpan.org/dist/Moose/lib/Moose/Manual/Roles.pod) As the original author of the patch Stefan Marr pointed out – traits are nothing more but a compiler assisted copy and paste. In true PHP fashion! What an interesting way to think about it. Conflicts and Aliases Ok, this is pretty cool. It's an edge case, but there's already a solution. Neat. Oh... wait a second, I think I've found the meat of it: Trait method definitions support all modifiers just like regular class methods do – that includes visibility modifiers, final, static and abstract. The latter can be used to define abstract methods expressing requirements for this particular trait So this is how they're slightly different than regular-old classes? By being able to use all the same keywords as regular old classes? It seems that the meat of it is at the very end: Traits only take part in the process of building a class and do not add any new run-time semantics. That means that usual PHP object-oriented functionality (like late static bindings) work as expected when combined with traits. But this next one is a bit of a gotcha: Traits can be composed from other traits (the same way classes use traits). Wait... what? Why would you want to do this? You're just getting back into hierarchies again... and pretty much just working around multiple-inheritance without calling it such. It's good to see PHP is evolving. Most people still think of PHP4 and shudder (and rightfully so). Evolving means it might be catching up to the superior languages it competes with in the web space. (Note the tongue-in-cheek). I'm still not convinced, but it's a step forward I am sure for PHP programmers everywhere. Just don't actually use trait-inheritance and you should be fine.
- epochwolf 16y ago
AndrewO 16y ago
It makes my skin crawl to see the first example use case be combining inheriting from singleton and the array class. It looks like PHP is finally getting advanced OOP features and the first thing someone wants to do with them is make a singleton (which violate single responsibility, also introducing global variables and tight coupling) that extends arrays (when delegating to an array instance is usually a better choice). I know this is a single example, but I feel like I've seen bad OOP practices in PHP so many times in the past. This is such a rich feature but it brings with it a lot of potential for misuse.
- simast 16y ago
  What's wrong with singletons in general and why would an object could not assume single responsibility (consider an UIApplication singleton on iOS)? I thought, contrary to what you stated, they solve the issue of global variables rather than introducing new ones. That class extends SPL ArrayObject class which provides array-like access syntax (operators). It does not mean it has to act like an in-memory array, it could read data from disk, session, database or whatever. Delegating this kind of functionality to a single array would simply not work without further abstraction.
  - pornel 16y ago
    Singletons don't solve problem of global variables, they are global themselves. They are global shared state than can be unexpectedly accessed from any place in the program. Encapsulation provided by singletons makes them even more problematic than global variables. You can temporarily overwrite global variable, run function that uses it, and restore global value. Singletons can be designed to prevent that, which kills testability of code that uses singletons (e.g. when you need to replace global DB connection with mock object).
  - barrkel 16y ago
    Singletons are global variables++. Read up on the capability security model and ambient authority (Mark Miller's erights.org, Gilad Bracha's Newspeak, Mark Miller's JS work eliminating accessibility of document etc. singletons for safely eval'ing JSON etc.) to understand the security, composability, testability and modularity issues with these idioms.
apinstein 16y ago
I read about PHP's traits on the RFC system a few years back. Knowing Traits and Closures were coming soon was one of the main reasons I decided not to bail for the ruby/python world. To me traits are actually a better solution than mixins via dynamism, since you get syntax checking via the compiler along with the benefit of compiled speed. You also have less confusion due to mixin conflicts. I am super excited about this. Thanks PHP!
HerberthAmaral 16y ago
So... do they figured it out how to fix the PHP's white screen of death? This kind of thing is so annoying that I can't even think of using PHP in my future projects.
- cheald 16y ago
  I'd assume you'd mean segfaults. It's somewhat painful to track down a segfault in PHP, but if you can compile PHP with debug symbols and then invoke a failing scripts under gdb, it's fairly straightforward.
  - viraptor 16y ago
    Syntax errors, calls to @nonexistant_name(), and many others will simply return an empty page and log the error to the error log (error is not catchable, so you cannot even return anything sane to the user) The fun starts when you hit one of the situations where the whole php stacktrace is `in file "" at 0` (or something similar). I've got 4 php programmers around me and I hear about the "white page" almost once a week, so it's not that uncommon :(
    - bluesnowmonkey 16y ago
      There are several ways of catching uncaught errors and returning reasonable output to the client. First look into set_error_handler and set_exception_handler. Also you can register a shutdown function or set an output buffer callback that looks at error_get_last().
    - mgkimsal 16y ago
      Well, you could turn display_errors to 'on' in the php.ini file, but this is generally regarded as a security issue, as the error message will reveal sensitive info. There are some situations which cause PHP to just die and not log anything, but those are pretty rare. It's pretty common practice to have display_errors to on for development, and off for production. Are you not doing that already? Or is everyone developing on production systems?
    - 16y ago
prodigal_erik 16y ago
If it's just compiler-assisted copy and paste, users should have been able to do it themselves rather than wait for the maintainers to add one instance of compile-time code generation (out of many more which still aren't present) that requires a platform reinstall to use. This is why languages should be extensible via something like macros.
heimidal 16y ago
At RubyConf last week, Matz (the creator of Ruby) introduced some of the ideas that are being tossed around for Ruby 2.0. One of these is called "refinements", and looks similar to what's being discussed in this article when it comes to method conflict resolution. Shudo Maeda, a colleague of Matz, went into greater detail about Refinements in his talk. You can find the slides here: http://slidesha.re/9rbfwN http://slidesha.re/9rbfwN
abalashov 16y ago
Why not just use include?
alkavan 16y ago
great news indeed. we are developing a dynamic (HMVC) CRM system using Kohana3 and PHP 5.2, traits can really help use do our CRUD system a lot more dynamic, and probably other stuff too. we are running the system on our own dedicated CentOS server ... and although we are developing with PHP 5.3, the most updated good package repository I've found is Jason Litka's repo, with PHP 5.2.x, he says he still got compatibly problems with the Zend Framework, so he won't update. so i guess using 5.4 on production will take some time. and i'm not talking about other virtual hosting providers who tend to update this things very slowly.
- bystac 16y ago
  I'm using latest php5.3.3-fpm without any issues. here corrected link to php53-fpm http://dl.iuscommunity.org/pub/ius http://dl.iuscommunity.org/pub/ius nginx latest repo http://centos.alt.ru/pub/repository/centos/5 http://centos.alt.ru/pub/repository/centos/5

85 points by simast 16y ago

5.3 => closure, 5.4 => traits, PHP's revolution? Honestly, I would prefer PHP remove all the bad parts of PHP before adding new things.

ameketa 16y ago
At least they didn't implement them by trying to come up with every possible mixin you'd ever want to write and then define them in the global namespace. Progress?
pilif 16y ago
Do you know how long it took to finally get rid of PHP 4? Do you know how long web hosters (and with that most open source projects targeting a wide audience) were sticking with PHP4? Even now that there won't be any more php4 releases, there are STILL projects targeting PHP4. There are STILL webhosts only providing support for PHP4. More than 5 years after PHP5 came out All this even though most PHP4 scripts run unaltered in php5. And now you suggest to drop backwards compatibiliy to get rid of warts? How long do you think it would take before that new language will get any significant deployment? What good will all the new features be if you are not able to use them in the next 10+ years? Personally, I like to see them add features in a backwards compatible way. Knowing PHP and programming in general, I can stay away of the bad parts but still use all the new features in the foreseeable (2-3 years) future. Just have a look at python3 of you want a taste if what you were just suggesting.
- tszming 16y ago
  I agree with you that incompatible changes by removing bad parts is definitely painful, but it makes PHP more sustainable in long term. This can happen in a more feasible way, e.g. freeze PHP5 (unlike the current situation), don't add any new stuffs; branch out a subset of PHP (removing bad parts), and continue the development there.
  - simast 16y ago
    Not sure of what kind of legacy features you would want to be removed but it's not like they are just building on top without thinking. PHP 5.4 will also drop: - safe mode - register_globals - allow_call_time_pass_reference/y2k_compliance and other legacy ini stuff - "continue 123" syntax (can be replaced with goto). As far as I recall this is done since it's barely used and if removed would allow to implement some opcode performance optimizations. Dropping some PHP 4 era syntax is obviously out of question due to already mentioned webhosting and backwards compatibility issues.
- wazoox 16y ago
  > Even now that there won't be any more php4 releases, there are STILL projects targeting PHP4. There are STILL webhosts only providing support for PHP4. More than 5 years after PHP5 came out The fact that PHP broke many websites when going from PHP3 to PHP4, then at each PHP4 minor release is probably largely responsible for this conservatism.
- robryan 16y ago
  Depreciating things is moving in the right direction, throwing a depreciated warning in the code. Slow but good way to change developer behaviors towards better PHP code. http://php.net/manual/en/migration53.deprecated.php http://php.net/manual/en/migration53.deprecated.php
  - bluesnowmonkey 16y ago
    Deprecating.
leftnode 16y ago
I love all of the new stuff coming to PHP, and frankly, I agree with you, but removing the "bad" parts would break so many applications. Standardizing things, making libraries consistent, and adding some type of strict typing would be the nicest things to do, I believe.
RossM 16y ago
A few of PHP's most (publicly) hated components are being removed in 5.4 (which may become 6, from what I can tell this article is lying when it says 5.4 is "around the corner") - register_globals, magic_quotes is being discussed. Even the old asp_tags setting is going. However these have no relevance to me as I haven't used them in years.
- robryan 16y ago
  If they are going that far, it would probably be better to get rid of more in one go, rather than giving people legacy code headaches with each release.
  - philfreo 16y ago
    What else do you think they should remove?
    - robryan 16y ago
      I guess I would focus on cleanup, method names and parameter orders. I don't know enough about the internals to know if also allowing say $var = $val->substring(0, 2); could be an alias to how values are currently passed into functions.
Nitramp 16y ago
Honestly, I would prefer PHP remove all the bad parts of PHP before adding new things. This has already been done, and the result is called "Python" (or Ruby, or ...). SCNR. Edit: ok, I realize this was maybe a bit too snarky. But I mean it: if you remove all the somewhat strange parts from PHP, you are breaking backwards compatibility. And at that point, your users have no reason not to move to another, maybe cleaner language (e.g. Python) all together. So if you want to get a cleaner PHP while breaking backwards compatibility, you might as well just use a different language.
xtho 16y ago
Considering how they implemented closures, I wonder what that revolution would look like.

deleted 16y ago

[deleted]

agentultra 16y ago

I don't understand the vernacular. One of the noteworthy language additions are Traits – a brand new horizontal code reuse mechanism. Code re-use mechanism? Horizontal? I didn't realize PHP was so geometric. What an interesting concept. While traits are technically different from mixins – they are both designed to fill the same gap left by a single-parent inheritance model So let me try and get this straight: mixins fill a gap left by a single-parent inheritance model and so traits are like mixins because PHP has a single-inheritance model but traits are technically different in some way? This is getting confusing... Python, Perl, Ruby, and many languages with multiple inheritance have been using mixins for... well a long time. It's pretty straight forward. Perl5 got "roles" through Moose and Perl6 has them natively. I think they're explanations are a little more clear. (http://search.cpan.org/dist/Moose/lib/Moose/Manual/Roles.pod http://search.cpan.org/dist/Moose/lib/Moose/Manual/Roles.pod) As the original author of the patch Stefan Marr pointed out – traits are nothing more but a compiler assisted copy and paste. In true PHP fashion! What an interesting way to think about it. Conflicts and Aliases Ok, this is pretty cool. It's an edge case, but there's already a solution. Neat. Oh... wait a second, I think I've found the meat of it: Trait method definitions support all modifiers just like regular class methods do – that includes visibility modifiers, final, static and abstract. The latter can be used to define abstract methods expressing requirements for this particular trait So this is how they're slightly different than regular-old classes? By being able to use all the same keywords as regular old classes? It seems that the meat of it is at the very end: Traits only take part in the process of building a class and do not add any new run-time semantics. That means that usual PHP object-oriented functionality (like late static bindings) work as expected when combined with traits. But this next one is a bit of a gotcha: Traits can be composed from other traits (the same way classes use traits). Wait... what? Why would you want to do this? You're just getting back into hierarchies again... and pretty much just working around multiple-inheritance without calling it such. It's good to see PHP is evolving. Most people still think of PHP4 and shudder (and rightfully so). Evolving means it might be catching up to the superior languages it competes with in the web space. (Note the tongue-in-cheek). I'm still not convinced, but it's a step forward I am sure for PHP programmers everywhere. Just don't actually use trait-inheritance and you should be fine.

epochwolf 16y ago

AndrewO 16y ago

It makes my skin crawl to see the first example use case be combining inheriting from singleton and the array class. It looks like PHP is finally getting advanced OOP features and the first thing someone wants to do with them is make a singleton (which violate single responsibility, also introducing global variables and tight coupling) that extends arrays (when delegating to an array instance is usually a better choice). I know this is a single example, but I feel like I've seen bad OOP practices in PHP so many times in the past. This is such a rich feature but it brings with it a lot of potential for misuse.

simast 16y ago
What's wrong with singletons in general and why would an object could not assume single responsibility (consider an UIApplication singleton on iOS)? I thought, contrary to what you stated, they solve the issue of global variables rather than introducing new ones. That class extends SPL ArrayObject class which provides array-like access syntax (operators). It does not mean it has to act like an in-memory array, it could read data from disk, session, database or whatever. Delegating this kind of functionality to a single array would simply not work without further abstraction.
- pornel 16y ago
  Singletons don't solve problem of global variables, they are global themselves. They are global shared state than can be unexpectedly accessed from any place in the program. Encapsulation provided by singletons makes them even more problematic than global variables. You can temporarily overwrite global variable, run function that uses it, and restore global value. Singletons can be designed to prevent that, which kills testability of code that uses singletons (e.g. when you need to replace global DB connection with mock object).
- barrkel 16y ago
  Singletons are global variables++. Read up on the capability security model and ambient authority (Mark Miller's erights.org, Gilad Bracha's Newspeak, Mark Miller's JS work eliminating accessibility of document etc. singletons for safely eval'ing JSON etc.) to understand the security, composability, testability and modularity issues with these idioms.

apinstein 16y ago

I read about PHP's traits on the RFC system a few years back. Knowing Traits and Closures were coming soon was one of the main reasons I decided not to bail for the ruby/python world. To me traits are actually a better solution than mixins via dynamism, since you get syntax checking via the compiler along with the benefit of compiled speed. You also have less confusion due to mixin conflicts. I am super excited about this. Thanks PHP!

HerberthAmaral 16y ago

So... do they figured it out how to fix the PHP's white screen of death? This kind of thing is so annoying that I can't even think of using PHP in my future projects.

cheald 16y ago
I'd assume you'd mean segfaults. It's somewhat painful to track down a segfault in PHP, but if you can compile PHP with debug symbols and then invoke a failing scripts under gdb, it's fairly straightforward.
- viraptor 16y ago
  Syntax errors, calls to @nonexistant_name(), and many others will simply return an empty page and log the error to the error log (error is not catchable, so you cannot even return anything sane to the user) The fun starts when you hit one of the situations where the whole php stacktrace is `in file "" at 0` (or something similar). I've got 4 php programmers around me and I hear about the "white page" almost once a week, so it's not that uncommon :(
  - bluesnowmonkey 16y ago
    There are several ways of catching uncaught errors and returning reasonable output to the client. First look into set_error_handler and set_exception_handler. Also you can register a shutdown function or set an output buffer callback that looks at error_get_last().
  - mgkimsal 16y ago
    Well, you could turn display_errors to 'on' in the php.ini file, but this is generally regarded as a security issue, as the error message will reveal sensitive info. There are some situations which cause PHP to just die and not log anything, but those are pretty rare. It's pretty common practice to have display_errors to on for development, and off for production. Are you not doing that already? Or is everyone developing on production systems?
  - 16y ago

prodigal_erik 16y ago

If it's just compiler-assisted copy and paste, users should have been able to do it themselves rather than wait for the maintainers to add one instance of compile-time code generation (out of many more which still aren't present) that requires a platform reinstall to use. This is why languages should be extensible via something like macros.

heimidal 16y ago

At RubyConf last week, Matz (the creator of Ruby) introduced some of the ideas that are being tossed around for Ruby 2.0. One of these is called "refinements", and looks similar to what's being discussed in this article when it comes to method conflict resolution. Shudo Maeda, a colleague of Matz, went into greater detail about Refinements in his talk. You can find the slides here: http://slidesha.re/9rbfwN http://slidesha.re/9rbfwN

abalashov 16y ago

Why not just use include?

alkavan 16y ago

great news indeed. we are developing a dynamic (HMVC) CRM system using Kohana3 and PHP 5.2, traits can really help use do our CRUD system a lot more dynamic, and probably other stuff too. we are running the system on our own dedicated CentOS server ... and although we are developing with PHP 5.3, the most updated good package repository I've found is Jason Litka's repo, with PHP 5.2.x, he says he still got compatibly problems with the Zend Framework, so he won't update. so i guess using 5.4 on production will take some time. and i'm not talking about other virtual hosting providers who tend to update this things very slowly.

bystac 16y ago
I'm using latest php5.3.3-fpm without any issues. here corrected link to php53-fpm http://dl.iuscommunity.org/pub/ius http://dl.iuscommunity.org/pub/ius nginx latest repo http://centos.alt.ru/pub/repository/centos/5 http://centos.alt.ru/pub/repository/centos/5