In his latest post, Brian Moon talks about a method to help you and your code fit into an E_STRICT style of coding - the settype function.

These days, the way to develop is to have E_ALL and maybe even throw in E_STRICT if you are really hard core. That of course means having all your variables initialized before they are used.

In his view, defining them is good, but it's more "elegant" to use the settype function to make it more clear where they are defined. He also includes a function, using settype, that ensures that the entered values are what they should be (i.e. and int is an int).

In his latest post, Brian Moon talks about a method to help you and your code fit into an E_STRICT style of coding - the settype function.

These days, the way to develop is to have E_ALL and maybe even throw in E_STRICT if you are really hard core. That of course means having all your variables initialized before they are used.

In his view, defining them is good, but it's more "elegant" to use the settype function to make it more clear where they are defined. He also includes a function, using settype, that ensures that the entered values are what they should be (i.e. and int is an int).

Lukas Smith has a quick post today about some of the tension that's come up between to PEAR error handling packages and something he's created to try to help calm things down.

Well there is a lot of back and forth about if PEAR should mandate PEAR_Error or PEAR_Exceptions or neither for new packages. This also relates to the question of PHP5 E_STRICT compliance which PEAR_Error obviously is not.

His quick fix for the problem? Two proxy classes that would make switching between either of the two error handling classes as simple as changing out which proxy you're using.

Lukas Smith has a quick post today about some of the tension that's come up between to PEAR error handling packages and something he's created to try to help calm things down.

Well there is a lot of back and forth about if PEAR should mandate PEAR_Error or PEAR_Exceptions or neither for new packages. This also relates to the question of PHP5 E_STRICT compliance which PEAR_Error obviously is not.

His quick fix for the problem? Two proxy classes that would make switching between either of the two error handling classes as simple as changing out which proxy you're using.