In this new tutorial from DevShed today they continue their series looking at making helper classes for your applications. This time they're focusing on using methods without needing to create an object first - static methods.

The methods of the class that I [just] mentioned were declared implicitly dynamic, even though it's perfectly possible to call them statically, and the PHP engine won't raise any errors about this process. However, it would be much better to declare these methods explicitly static, thus taking advantage of the functionality offered by the text helper class without having to spawn an instance of it.

They show how to define the methods with the "static" keyword so they can be called outside of the class' scope. Code for the helper class and the code to put it to use.

The Zend Developer Zend has posted the announcement that the Call for Papers for this year's ZendCon - The PHP Conference has been opened.

Welcome to the Call for Papers for the 2009 edition of ZendCon '" The PHP Conference. This year's conference will be held October 19th '" 22nd at the San Jose Convention Center and is being co-presented by S&S Media. It is the largest gathering of the PHP Community and the premier PHP conference, allowing all attendees to mingle with decision makers, core developers, prominent community members, and so many more.

The scope of this year's conference has widened a bit and won't just be about PHP-related topics. Proposals for sessions about things like project lifecycle, frameworks, and performance tuning will also be accepted. There will be five different tracks this year:

• Server/Operations
• Lifecycle Best Practices
• Frameworks
• Real World PHP
• PHP Development Topics

The Call for Papers ends May 31st, so get over and submit your proposal before time runs out!

Leonid Mamchenkov has compared Perl versus PHP in this new blog post - specifically how they handle variable scoping.

I've mentioned quite a few times that I am a big fan of Perl programming language. However, most of my programming time these days is spent in PHP. The languages are often similar, with PHP having its roots in Perl, and Perl being such a influence in the world of programming languages. This similarity is often very helpful. However there are a few difference, some of which are obvious and others are not.

His example compares looping (a foreach in both) and how, after the Perl loop the $value variable is no longer accessible. In PHP, however, it's passed back out into the current scope and can be read just like any other variable. While this can be useful, it can also cause headaches when trying to track down elusive bugs.

According to this new post on the Typical Programmer blog, using getters and setters in your scripts only adds in a bit of unnecessary coupling and complexity to your scripts that you just don't need.

Today most of the popular programming languages support objects, limiting scope, modularity, passing by value, and sophisticated built-in types. There should be no reason to deliberately expose an object's data to the rest of the code because the language can enforce encapsulation and data hiding.

While not specific to PHP, the post does recommend against them because of one simple reason common to all languages that make them possible - they "break the encapsulation OOP offers". For them, they're like a cheat to get around bad coding practices and are not needed to make a successful application work.

In his latest blog entry, Mike Naberezny takes a look at the Symfony framework and shares some of his opinions on it.

One thing that I think Symfony gets right is that it appears to use partitioned PHP code for its templates, in the spirit of Paul's Savant system.

I noticed in the Symfony demo that there is no separation of scope between variables passed to the template from the controller and local variables in the template. I'd like to see them scoped properly ("$this->products") but I can certainly understand why they did it this way. Using "$this->" in the template everywhere quickly gets messy.

He mentions a few other items he saw as well, including a way to correct the above mentioned problem (two ways - one more single-instance, the other more global).

Mike Naberezny has posted a few more articles to the "Rails for PHP Developers" website (based on this book) covering some more of the basics.

There's three new tutorials posted:

• Ruby Block Scope - the basics of Ruby block scope, a common point of confusion for PHP developers new to Ruby.
• Variable Arguments - an article that shows two common API patterns found in Rails, variable arguments and option hashes, and how to implement them both in PHP.
• Regular Expressions in Ruby - a useful reference that maps all of the common PHP regular expression functions to the equivalents in Ruby.

Check out the rest of the site for even more great content.

<> In this new post to the SitePoint PHP blog, Troels Knak-Nielsen talks about some of the advancements (and diagreements) that have happened around adding lexical scope to the create_function functionality.

The main argument against approving the patch, seems to be, that one would expect static scoping rules to apply to the anonymous function. After all, this is the case in similar languages, which support anonymous functions. One could only assume, that changing PHP to support this, would be a major undertaking.

One would be wrong, it seems.

A patch has been made to add the functionality (from Christian Seller) adding a new keyword, lexical, to make it all work.

Arnold Daniels points out a quick method for creating what he calls "perl-like temporary variables" in the global scope of a script:

When writing code in the global scope, I often have a problem where I'm overwriting a variable. This happens even more often when I work on code of somebody else. Usually has the variable which does the overwriting is usually just a temporary variable.

His code is a simple few lines that shows how it could be used when trying to write information out to a file handle. Some of the comments on the post criticize his use of the global scope but Arnold comes back with his reasoning - mostly that there is already code in the global scope and that adding something else is only adding to it, not making things worse.

On the I/O Reader blog, there's two different posts that take two sides of the spectrum when it comes to what to like and dislike about PHP, both lists of features of the the language:

• 15 Cool Things About PHP That Most People Overlook - a list including the Reflection API, the Standard PHP Library, type hinting and the "magic" functions.
• 12 Things You Should Dislike About PHP - this list includes things like naming conventions, that _tostring doesn't work as (he) expected, magic quotes and register globals and safe mode

Both have their valid points and it's interesting to see how many of the points made in the first article he goes back on and mentions specific instances where it doesn't work as expected. Some of the comparisons seem a bit like he's comparing PHP to his experience in another language and not objectively on PHP's features alone.

On the PHP 10.0 Blog, Stas talks more about inlining in PHP functions - some of the bad things this time (see here and here for other comments), including things that could break an application if not handled correctly.

Performance benefits from inlining simple functions might be significant, since function call in PHP is not cheap. We'd have some potential problems there.

Included in the list are things like:

• Variable scoping - we don't want function variables to mess with our scope, so we'd probably rename them or something.
• Then we might get a problem if function messing with current scope is called indirectly so we can't really know.
• And then some may use end-of-scope for destruction of variables that have dtors, so when we'd clean up these variables?