Comments on: PHPundamentals Series: A Background on Statics (Part 1 on Statics)

By: phpcurious

phpcurious — Fri, 04 Nov 2011 18:45:22 +0000

Great article, when are you going to publish the follow up? Any solution on how to remedy the issue posed by PHP architecture?

By: Dirk Louwers

Dirk Louwers — Tue, 19 Oct 2010 08:25:30 +0000

“If you need to persist state – whether it’s data, objects, or whatever – then persist it correctly. Use MySql, or Sqlite, or memcached, or CouchDB, or who cares.”

I couldn’t disagree more. Apart from the quirky UTF support in PHP5 the lack of a true application scope is something I miss most! In most of my applications there is plenty of data that is already properly persisted, like in a configuration file or annotations for instance. Often parsing this data on a per request basis is unacceptable from a performance standpoint. Serializing this data alleviates the pain somewhat but still carries a performance penalty. The best solution I’ve found so far is translating such data to PHP classes so that in combination with an opcode cache the data can be made available as quickly as possible, but this is by far more contrived than using application scope for this. Just my two cents.

By: Giorgio Sironi

Giorgio Sironi — Sat, 08 May 2010 10:03:58 +0000

I disagree with calling ‘static&global’ what is really an application scope.
The important difference is between the shared-nothing architecture of PHP applications and the shared application scope of a Java Servlet application, but there’s nothing inherently static in them.
In fact, a good rule to see if you’re doing things right is the ability to run two identical applications in the same JVM. Global [variables] are hidden dependencies; static [variables, method, classes] are similarly hidden dependencies.
An example of this is Zend Framework’s Zend_Test component, which because of the singletons usage for sessions and front controller, has to reset the various components manually between tests, instead of simply creating a new application object.

By: George Mauer

George Mauer — Sat, 08 May 2010 01:03:27 +0000

Ok, I’ll bite…

You deserve a berating for not mentioning the biggest thing about statics: (public) statics have no limitations on visibility. Fully allowing that I might be missing something, but statics in PHP are conceptually equivalent to global variables. Presumably you’re going to argue that that is not necessarily bad – and from a memory management perspective you’re right. From a making-your-application-maintainable perspective globals – as you know – are a nightmare. Especially since its usually perfectly possible to limit the scope of your variables. Heck, with the shared-nothing thing, I’ve never quite understood why php went head-first into OO, a functional paradigm with tight immutability rules seems like a much better fit.

Now, regarding Java/.Net – statics are generally allowable only in situations where you do not persist state such as helper methods or DSLs. Even there they are discouraged. The only place I would ever see a static state in a well-constructed C# application (stupid ASP.Net framework nonsense aside) is when using a Service Locator – and even that I’m generally uncomfortable with as there is almost always a better way.

If you need to persist state – whether it’s data, objects, or whatever – then persist it correctly. Use MySql, or Sqlite, or memcached, or CouchDB, or who cares. Statics are a tempting way to do it, but its way too easy to get into trouble with them. Yes, the fact that PHP limits them to the scope of the request limits their damage potential but reading your average PHP code is difficult enough – please don’t recommend people to make it harder.

By: Ralph Schindler

Ralph Schindler — Thu, 06 May 2010 20:07:24 +0000

Hey Bruce, I basically mean “Do you not get how they work?”. The point of this article is to fully understand the scope of static members. Originally, this article was much longer, but when I realized how long this way, I decided to make a series of them. This is just a background article. The next articles will attempt to describe the persistence problem we have in PHP, look at the solutions.. then move into the “static argument” – what are they good for? Are they really as evil as globals? And, of course, we’ve all heard the expression: “Singletons are evil, never use them..”, we’ll discuss where that argument came from and how it applies to PHP.

Hopefully you’ll stay tuned, I’ll try to deliver the point in a few days- I am just laying some ground work.

-ralph

By: rafaelxy

rafaelxy — Thu, 06 May 2010 19:07:04 +0000

Great article, I’m looking forward to read the next one =)

By: Bruce Weirdan

Bruce Weirdan — Thu, 06 May 2010 18:56:35 +0000

> Still don’t get it?
Don’t get what exactly? What is the point you’re trying to drive home?

By: Mandi

Mandi — Thu, 06 May 2010 18:13:12 +0000

Very good starting article! Can’t wait to see how the series of these articles continues

By: Kevin Bruce

Kevin Bruce — Thu, 06 May 2010 17:06:52 +0000

Thanks for this article. Having really only worked in PHP, it’s good to know the differences between the major web languages. It explains allot about how we, as PHP developers” have to “fake” a persistent state with sessions, cookies and database storage in order to have a consistent state on a visitor’s return visit.

By: [ this is jerry ]

[ this is jerry ] — Thu, 06 May 2010 16:34:12 +0000

Great article, Ralph. Thanks for educating us.

What I always find interesting is how individual coders solve issues that arrise because of this. For example, MaxMind uses shared memory (http://geolite.maxmind.com/download/geoip/api/php/).