Attributes

Attributes are “extra” bits embedded in source code that doesn’t necessarily mean anything in the language. Common examples include the documentation annotations in many comment systems (such as the tags used in Javadoc comments), JVM annotations, and .Net attributes.

A testing framework, for example, might use a TestFunction attribute to identify which methods should be called.

@TestFunction
public function testValidation() {...}

[TestFunction]
public function testValidation() {...}

Use cases

In Java EE you have “beans” which encapsulate business logic. Each bean requires a bunch of wrappers for remote access, “home” access (whatever that means), XML files, etc. Keeping all this relatively “boiler-plate” code in synch is painful. Annotating the bean classes and methods with attributes makes it possible to generate most of this automatically. No more manual synching XML files.

Java, though, (as of Java 5) has built in support for annotations and is a compiled language. This makes it relatively simple to do this analysis and generation at build time. PHP, on the other hand, doesn’t have an annotation mechanism and doesn’t have a built time.

Instead, Peter’s approach is to use PHP comments to add the attributes. At load time, these comments are processed using the reflection API and this is used to build a data structure to use for access control. See the permissions example.

A more complex case

To take this a little further, Peter wrote a Zend extension that makes it possible to [sort of] do aspect oriented programming (on function points) in PHP. The add_function_hook() function allows you to register an attribute and a callback and the extension will call your callback before a function with that attribute is executed:

<?php
class RequiresLogging
{

	/**
	 * @log notice "Secret action performed by user [user]
	 */
	public function secretAction()
	{
		// perform secret action...
	}

}

// 
// The callback function
//
function performLog( $message )
{
	$parts = split( " ", $message, 2 );
	$level = $parts[0];
	$message = $parts[1];
	Logger::log( $level, $message );
}

// 
// Register the callback
// 
add_function_hook( "log", "performLog" );

// Now code like this will result in a log message being recorded
$object = new RequiresLogging();
$object->secretAction();

This type approach is flexible and extremely powerful. You can inject permission checking code and raise an exception before the real function is even called.

There are a bunch of memory leaks and possible bugs in the Zend extension, but it is working and in production use!

He started with a list of things that have been removed or altered in PHP6 and then described some of the new features. Some of the things from both lists are present in version 5.3.

Removals and changes

In PHP6 E_ALL will include E_STRICT which may cause errors to be reported in code that is OK in PHP5. A new E_DEPRECATED has been introduced and is also included in E_ALL. This new error is raised when you use any deprecated functions.

These deprecated functions and features include register globals, magic quotes, safe mode and ASP-style <% %> tags. Also going/gone are the $HTTP_POST_VARS and $HTTP_GET_VARS variables.

Other changes include assign-by-reference (using =&) and zend_compat raising E_STRICT. Class members defined without a visibility modifier will be public by default (and will also raise E_STRICT).

Dynamically loading extensions is now disabled by default on all SAPIs except the command-line interpreter. This needs to be enabled (in php.ini, I assume) if required.

In a rather acrobatic backflip, the formerly deprecated $str[1] is no-longer deprecated and its replacement $str{1} now is deprecated. You can also now use the subscript syntax to take a slice of a string – like $str[1,3] – as you in some other languages.

The wacky variable break feature (where one breaks out of a variable number of looping constructs: break $anint;) is deprecated. It’s disappearance make me wonder (again) why it was added in the first place. I can’t help but wonder if there was a use-case in mind, or if it was just “because”.

The microtime() function now returns the float value by default; you’ll no longer need to use microtime(TRUE) in every invocation.

The move to using the PCRE-based preg_* functions for regular expressions is finally complete. The ereg_* functions have been removed from core and stuck in a PECL extension. At the same time, mime_magic has also been moved to a PECL extension and its more useful and popular cousin fileinfo has replaced it in core.

Additions

The big ticket new item must be namespaces. The controversial choice to use backslash as the separator was due to the simple fact that it is the only single character available. This doesn’t make it any less silly, especially because of the way that function “references” in PHP are just strings:

$func = "\application\names\afunc";
$func();

All names refer to the current namespace, but prefixing a name with a backslash will make it relative to the “root” namespace.

You can import things from other name spaces with the use keyword and, if required – perhaps there is a clash – alias them by taking an as clause on the end:

use \MyCompany\Blog\User as BlogUser;
use \MyCompany\CMS\User as CMSUser;

Functions and classes both belong to namespaces and definitions are processed top-down. Thus the following code defines a foo() function and then a bundle\foo() function:

function foo() { echo "G"; }

namespace bundle;

function foo() { echo "NS"; }

bundle\foo(); // "NS"
foo(); // "G"

Another important change is the addition of late static binding. In previous versions of PHP self::foo in the code of a superclass method refers the foo member of that superclass, even if the subclass defines a foo member. This problem is ameliorated with the addition of a new static keyword. static::foo will do what you expect: look in subclass, then in the parent/s.

All in all, it looks like PHP6 is a great big leap forward in the evolution of PHP. A few more major versions and it might catch up to modern languages.

After a bit of background on the mainframe, mini, server, desktop progression, Guiseppe introduced the space that Gearman operates in: distributed heterogenous system (like the web). Amongst Gearman’s peers in the space (not to say that they fill the same role 2at all) is memcached.

Gearman is a client/server system for distributing jobs from clients to a number of workers. Guiseppe drew an analogy to a manager in a company: the manager gets a request from a customer, delegates it to one or more employees, and hands the result back to the client (monitoring progress along the way and assigning the job to new employee/s if the current ones are, e.g., hit by a bus).

The Gearman server fills the role of the manager: it accepts connections from clients and one or more workers (which can be local to the server or on other hosts). The Gearman server is responsible for then farming the jobs submitted by the clients out to appropriate worker/s for execution.

There are a numerous ways that this can be useful. It can help to decouple applications and features from each other. Rather than re-writing existing components for use in projects in another language or on a different platform, you can use Gearman to mediate the invocation of the existing code from the new system. Similarly, you can use it to offload computationally intensive tasks to more capable systems.

Using Gearman is reasonably simple: the gearmand server is written in C and there are client libraries available for, according to Guiseppe, “everything that counts”: C/C++, PHP, Python, etc. You just start a server, start one or more workers, and then use one (or more) of the available client libraries to submit jobs.

# Start a server
PORT=1234
gearmand -d -v -p $PORT

# Start a worker
gearman -p $PORT -f count_lines -- wc -l

# Submit a job
gearman -p $PORT -h localhost -f count_lines < /etc/passwd

The above code starts a Gearman server, starts a worker that can compute the count_lines function (by running wc -l on its input), and submits a job.

There are some rather more complex uses. One of those that Guiseppe mentioned is using the client in user defined functions in a relational database server (he used MySQL, but PostgreSQL is also supported). With appropriate jobs and workers this can be used to retrieve status information from, e.g., MySQL slave servers and store it in a database on the master (which will then be replicated to the slaves giving all nodes knowledge of the health of the whole cluster).

To help avoid introducing a single point of failure, you can deploy multiple servers and use all of them: if one fails, then clients and workers will try the next. It wasn’t clear, though, if the client libraries do this sensibly (re-submitting jobs, etc.)

For more information, your first stop should probably be the official Gearman web-site. There are also a number of posts on Guiseppe’s blog.

The talk, aimed at newcomers, covered a lot of ground. It started with a characterisation of Haskell as a pure, functional, non-strict, strongly, statically typed, programming language and gave all the usual reasons that those are nice properties for a programming language to have.

After a few examples of the syntax, Stephen talked about recursion and mentioned that idiomatic Haskell tends to use a higher-order function implementing a particular recursions scheme, but didn’t really point any out (other than using map in example).

Next was a brief discussion of the type system: it’s strong and static, but it also features type inference so you don’t need to supply signatures for everything. It’s probably important to note though, that it’s still a good idea for top level definitions for documentation purposes, if for no other reason. Next was a mention of QuickCheck and automatic testing.

Finally, there was a bit about Haskell’s non-strict semantics and the usual points about concurrency (being hard in imperative languages and rather easier in Haskell). Laziness is useful as it makes it possible to represent [potentially] infinite data structures and looping data structures without destructive updates, alas it can make it hard (or, at least, harder) to reason about and predict the time and space behaviour of a program.

It was a pretty good talk, but I though Stephen missed a few opportunities to make some important points that the audience might have appreciated. In particular, I’d have mentioned the various higher-order recursion operators and opportunity they provide for automatic application-specific optimisations through fusion. This is the sort of thing that is difficult or impossible in a lot of languages but are seriously cool!

1. a nice-ish bag;
2. a few note books;
3. a USB flash drive with the programme and such;
4. the requisite t-shirt (and a hat)
5. some sunscreen (optimistic) and Lynx stuff (a very good idea!)

and some other stuff that I forget.

The newcomers session afterward with Rusty Russell and a woman whose name I didn’t catch me was informative and entertaining. They covered the programme and talked about past LCAs, but the most useful is likely to be the “Advice, Secrets and Lies” that many people wish they’d known before their first LCA.

Do

Attend the full conference, especially the keynotes!

Turn up to talks and actually pay attention! Don’t turn up and spend the session reading email.

If you see something wrong, help out!

Don’t leave rubbish in the theatres or anywhere else!

Get some rest! The week is something of a marathon. You’ll need it.

Blog, photograph, tweet, etc. Use the #lca2010 tag so that people can find your stuff.

Do not!

See nothing while hanging out on IRC.

Drink more than you usually do. (There’s a tradition that at least one attendee or speaker is hospitalised each year: don’t be that person.)

Fanboy!!!! the speakers.

Harass others.

Join or start more than one new project. It seems like a good idea, but it’s not. Pick one thing to get enthusiastic, you’ll never have time for more than one anyway.

Believe that your ssh keys have changed.

Secrets

The attendees are the conference. They are interesting (and some of them are speakers!) so speak to them.

The badge has annotations on it. There’s a colour scheme (orange for hobbyists; blue for professionals; red for speakers or something), the fish heads represent tickets to the Penguin Dinner, the radio thingo to the Professional Networking Session, the map your origin, and a few other things.

Surprises (often at keynotes, yet another reason to attend them)

The in jokes (laugh along, write them down and ask about them later)?

Next year’s conference (usually announced at the Penguin Dinner).

All the stories about things that “always happen” at pretty much lies. It’s different every time and, while there’s a few things that happen often, they’re

Now, we’re off to the Green Man pub.

I’m looking forward to seeing just how much Linux has changed since I last built my own kernel (circa 2003).

I’ll be going to the Open programming languages, Multicore and Parallel Computing, Data Storage & Retrieval, and System Administration miniconfs. Session wise, I intend to look in on most of the kernel and low-level user space talks that I can.

After LCA per se is done (but during open day, unfortunately) I’ll be at DrupalSouth to pick up some more Drupal-fu by osmosis.

If you’re interested, you can see more LCA and Drupal specific articles in the LCA archive and Drupal archive.