Nikita Popov has a new post to his site looking at how you can add your own syntactic features directly to PHP (requires knowledge of the C language).

Several people have recently asked me where you should start if you want to add some new (syntactic) feature to PHP. As I'm not aware of any existing tutorials on that matter, I'll try to illustrate the whole process in the following. At the same time this is a general introduction to the workings of the Zend Engine. So upfront: I apologize for this overly long post.

He covers the usual "life" of a PHP script, how tokenization is handled and what happens when the script is parsed, compiled and executed. Code snippets are included to show you the points to add in your own syntax item - in their case, adding an "in" operator to see if a value is in an array (a one word version of this).

On PHPMaster.com today there's a new tutorial showing you how you can use YAML documents on your applications ("YAML Ain't Markup Language") for configuration files.

Test fixtures, configuration files, and log files all need to be both human and machine readable. YAML (YAML Ain't Markup Language) is a less-verbose data serialization format than XML and has become a popular format among software developers mainly because it is human-readable. YAML files are simply text files that contain data written according to YAML syntax rules and usually have a .yml file extension. In this article, you will learn the basics of YAML and how you can integrate a PHP YAML parser into your projects.

They start with a brief introduction to the YAML syntax by comparing them to the structure of a typical PHP array. They include the YAML output from these examples and how, despite the ease of its use, it shouldn't be considered a replacement for something like XML (they both have their strengths). He points out some of the current YAML parsing libraries and how to integrate them into your app (he uses the Symfony option).

PHPMaster.com has a new article for those new to the PHP language posted this morning - an introduction to using functions and making your code more reusable.

Let's start by defining the word "function." A function is a self-contained piece of code which carries out a particular task (or function!). A key benefit of using functions is that they are reusable; if you have a task that needs to be performed a number of times, a function is an ideal solution. They can be either defined by you or by PHP (PHP has a rich collection of built-in functions). This article will focus on programmer-defined functions but will touch briefly on PHP's functions to complete the picture.

They include a few code snippets showing the syntax of functions (including their name, arguments and returning a value). They suggest grouping your functions together in your code for easier maintenance and share a handy tip on making a function accept a varying number of arguments.

On PHPMaster.com today there's a new tutorial showing the use of a sometimes overlooked (but very handy) alternate syntax that PHP includes - the ternary operator, a short-hand if/else.

You're probably already familiar with PHP's if statement. It's very similar to its counterparts in many other programming languages and represents one of the most fundamental concepts in programming. [...] But there's a way to build on this concept and increase your $coolFactor a bit in the process. Allow me to introduce you to the ternary operator, which serves as a shorthand notation for if statements.

They introduce the ternary operator's syntax, the ":" and "?" operators and includes a few pieces of code showing its use. Thankfully they also include a warning - don't overuse or abuse it...and especially don't nest them - that just leads to headaches.

On the DeveloperDrive.com site today, there's a new post with a few reminders for PHP developers out there of things it's easy to forget when writing your applications - some common mistakes to avoid.

Despite the high expectations placed on them at times, developers are human. They were the last time we checked anyways. As humans, we are bound to make mistakes from time to time. And simple, common mistakes often slip past our filters the more comfortable we become with something. [...] But knowing what these common mistakes are and how to avoid them can really help speed up the development process and keep our clients smiling.

His list includes three big ones that, if forgotten, could end up being detrimental to your application (sooner or later) - poor housekeeping/organization of code, forgetting punctuation and forgetting to validate input from users.

On Hyperpolyglot.org there's an interesting listing of scripting language syntax - PHP, Python, Ruby and Perl - showing some of their common syntax and data structures side by side.

Sections of the reference sheet include

• arithmetic and logic
• arrays
• execution control
• libraries and modules
• objects
• reflection

It's interesting to see how the various languages compare, where some have shortcuts for things and others fail at the same (or make it much more difficult). Descriptions for the different row types are also included.

In a recent post to his blog Stas Malyshev talks about shortcuts - those things that languages include to make your code shorter and your life easier...or do they?

PHP is notorious among scripting languages for it's verbose syntax - you have to spell out many things that are much shorter in other languages. Some people think it's very bad that they can't be "expressive", meaning writing more clever code with less keystrokes. Sometimes they are right, sometimes they are not.

He talks about the upcoming syntax change in PHP 5.4 for defining arrays (being able to use square brackets) and how it makes sense based on the standards of other languages using a similar syntax. He gives one bad example from Python, though - how Python 2 handled the catching of exceptions and assigning the result.

Some people in PHP community think all "shortcuts" are best to be avoided. I think some of them could be useful, provided clarity is not sacrificed and there's not "too much magic".

Freek Lijten has a recent post looking at some of the types of discussions that happen on the php-internals mailing list.

The internals list is the place to be to hear about the current state of PHP. It is one of PHP's many mailing lists, but this is the one where (core) developers discuss new features, current bugs and wild ideas. If you want to keep up with things it is a good idea to sign up, it is not an extremely high volume list and if you ignore the noise it is quite informative. In this article I would like to share examples of stuff typically discussed on the list.

He mentions feature requests in general and, more specifically things like traits support (multiple inheritance), array dereferencing, callable arrays and the debate over the short array syntax.

On RubySource.com there's a recent post with a bit of a confession from an ex-PHP developer who's moved over to Ruby about some of he is experiences in making the shift and why he's a convert now.

I've been a PHP developer for nearly a decade, and in January this year I started developing in Ruby. While initially a sceptic, I'm now a convert - and I'm here to share my experiences with you. [...] I'd like to think of myself as a fairly good PHP developer, and the idea of moving to Rails was both scary and exciting. [...] In Ruby's defence, these are frustrations that are well made up for with the delights of finding out how easy other things are to do - and any learning process has its frustrations.

He compares a bit of code that would take a list of email addresses and pull out the domain parts of each, grabbing only the unique ones. He includes some PHP code (using anonymous functions in PHP 5.3) to get the job done and compares it to the Ruby method that's a bit more fluid and readable. He talks about some of his frustrations during the learning process of creating code like this and includes his steps as he evolved through it.

On the ServerGrove blog today there's a new post showing how you can set up Dreamweaver to be able to edit Twig templates directly, complete with syntax highlighting.

If you are a designer working with Symfony developers you will soon encounter Twig. Twig is a template engine for PHP that has been adopted by Symfony 2, and from a designers perspective, it's a major improvement over the way things are done in Symfony! For designers who have used templating systems like Smarty before, Twig is going to be a walk in the park, if you have not used a templating system before, Twig is a great place to start.

It's a simple two-step process to get things up and working. You just need to tell Dreamweaver that ".twig" files should be recognized as code and set up the syntax highlighting in the "MMDocumentTypes" XML configuration file (might be a little tricky for non-development types). This change tells the program to open them with HTML syntax highlighting.