Comments for Ralph Schindler

Comment on Compiling Gearman (or anything) for Zend Server CE on Snow Leopard by Webs Developer » Ralph Schindler’s Blog: Compiling Gearman (or anything) for Zend Server CE on Snow Leopard

Mon, 17 May 2010 17:30:32 +0000

[...] Schindler has put together a guide for compiling gearman on Zend Server CE (or really anything for that matter). Zend Server CE for Mac (as of this writing), comes compiled [...]

Comment on Compiling Gearman (or anything) for Zend Server CE on Snow Leopard by Ralph Schindler

Ralph Schindler — Mon, 17 May 2010 16:39:49 +0000

Optik,

To my knowledge, that is correct. Generally inside a header file you’ll see architecture specific if blocks. For example, in event.h (on my system, part of libevent), you might see #ifdef WIN32 … #else … #endif

-ralph

Comment on Compiling Gearman (or anything) for Zend Server CE on Snow Leopard by optik

optik — Mon, 17 May 2010 16:05:07 +0000

Thanks, I haven’t solved this multiarch problems yet, hence just maybe stupid question. Header files (not only for gearman but generally) are always architecture independent?

Comment on PHPundamentals Series: A Background on Statics (Part 1 on Statics) 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.

Comment on PHPundamentals Series: A Background on Statics (Part 1 on Statics) 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.

Comment on PHPundamentals Series: A Background on Statics (Part 1 on Statics) 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

Comment on PHPundamentals Series: A Background on Statics (Part 1 on Statics) by rafaelxy

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

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

Comment on PHPundamentals Series: A Background on Statics (Part 1 on Statics) 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?

Comment on PHPundamentals Series: A Background on Statics (Part 1 on Statics) 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

Comment on PHPundamentals Series: A Background on Statics (Part 1 on Statics) 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.