[In a Service Locator] all the dependencies are provided by a builder, which serves as a registry of dependencies and/or service definitions. The service locator knows how to instantiate each dependency. Such service exposes methods like 'getMailer()', 'getLogger()' etc. A service locator centralises the configuration detailing classes and parameters involved on objects instantiations.

He includes some sample code showing the structure of a Select implementation using a "Mailer" identifier and definitions of the classes to load for it. He also includes a bit of documentation of the (simple) API you can use to work with the tool - setting namespaces, replacing class definitions, creating definitions and finding the resource associated with a definition (to name a few).

Sigh. What a difficult question. There are numerous incarnations on StackOverflow. All nearly unanswerable. The worst part is questions where they add the "in general" qualifier. Which is "faster in general" is essentially impossible to answer. And yet, the question persists. There are three rules for figuring out which is faster. And there are three significant problems that make these rules inescapable.

His three rules are:

• Languages don't have speeds. Implementations have speeds.
• Statistics Aren't a Panacea.
• Benchmarking Is Hard.

He seems to hit most of the issues with these sort of "faster" posts up front and notes that, while benchmarks can be run on a lot of different aspects about the languages, the results depend on how you slice it. His suggestion is, instead, to not try to compare the languages in a grand sense. Take each of them and compare them on specific tasks and let those results stand alone. Each of the three languages is going to be better at something than the other two.

Imagine the possibilities when a PHP developer can continue using the language's templating capabilities while leveraging Hibernate's object-relational features. Thanks to an open source project named Quercus, PHP and Java developers alike can mix and match the respective capabilities of both languages. [...] This approach (part of the movement that software architect Neal Ford famously defined as "polyglot programming") opens up a whole new world of opportunities for developers seeking to squeeze every last ounce of performance and capability from their application platforms.

They help you get it installed and show you how to execute a PHP script from inside. There's also a bit about integrating Java libraries into your code and the integration of a type of tool PHP doesn't come native with, something like iTextPDF.

The first thing to clarify is that I like the new implementation overall, it's fairly light and although it isn't really namespacing or packaging in any sense of the word, the best way to describe it is aliasing, it does help keep code easy to use. In fact I have a couple of projects and even a PHP extension that's all namespaced code.

Her list of five (four and a half) things are:

• multiple namespaces in a file
• you can't have ANYTHING before the namespace statement but an opening <?php tag
• The autoload and resolution paths
• Functions in namespaces
• No use * and three million use statements (this is the one with the workaround - class_alias)

Options this time were:

• Don't use underscore in host names
• Commit your session before it redirects
• Prevent session fixation
• Don't expose session_id's

Subversion and Symfony users should cast their votes in this week's poll. It asks, of the four options given, which is your favorite "trick" to running the Symfony framework with Subversion.

The posts will be researched and go through multiple drafts for professionalism before posting. In this hope, it will strive to enable discussion that isn't flaming and collective of the topic at hand. For as much as I can achieve at my level of writing skill and researching the topic at hand.

He he goes through the purpose of the posts, the areas he's going to focus on, some about the theory that will be used, and the implementation and documentation he'll provide through the series.

Conceptually, location based searching is pretty straight-forward: find out where you are, find out how far you're willing to travel, and compare your location against the locations of all your choices. If the distance between where you are and what you're interested in is less than what you're willing to travel, add it to your results list. Simple, right? Right.

He talks more about the concepts behind the search and one of the keys to the entire process - geocoding. They opted to go with the Yahoo! Maps API to grab this information. There's some sample REST urls and the output of the results after they've been unserialized.

They've even created their own class to make things even simpler. It does require that you have cURL installed with your PHP5 installation, but outside of that, there are no other dependencies.

He talks about a history of how things go to where they are, starting back with regular CGI scripts, moving up through using server-based APIs, and finally to FastcGI, a method for overcoming a lot of the limitations of its predecessors.

With that look back, he turns his attention around and looks to the current situation within PHP. He talks about the sudden appearance fastcgi made in PHP's SAPIs, but that the implementation wasn't true. He suggests that the reasoning behind this "fake" implementation was for the sake of speed. He also notes, however, it's his opinion that true FastCGI support in PHP will be a requirement for future large-scale applications.

He jumps right in, mentioning the steps the script will take (seven of them) before getting right to the code. He's written up his own soundex functionality packaged up nicely in a reusable function and has even compared it to the built-in PHP soundex function for accuracy.

Here, I'm not going to offer a full reference for what each design pattern is. You can buy a book to learn that, or even do some "googling" and find other helpful resources that probably will treat the subject much more extensively. Instead, I'll provide you with a concise explanation of what an Iterator is, in conjunction with numerous sample codes, which hopefully will help you understand much more easily how it can applied in PHP object-oriented programming.

They start off by looking at what the Iterator pattern is - the setup of a pseudo-class and an explaination of how it works. They follow this with a functional example and creating a subclass off of the generic base class.]]> Thu, 09 Mar 2006 07:12:15 -0600