Article by me in next issue of .NET

You might recall I did a tutorial last year for .NET Magazine, an introduction to regular expressions. Well, the next issue (?) will feature another one from me - this time, a jQuery catch-up piece.

The premise is this: many developers got comfy with earlier versions of jQuery. A scout around some big traffic sites proves this; many are still on 1.4 or 1.5.

But jQuery hasn't sat still; it has developed, and at some pace. The article will look in turn at jQuery 1.5, 1.6 and 1.7, covering some of the main features in each release:

Deferred objects

I'm a particular fan of the deferred objects concept, and jQuery's implementation of it is a good one. They offer a wealth of flexibility with regards to how you approach callbacks to asynchronous - or even synchronous - operations. These arrived in jQuery 1.5 as part of a major overhaul to jQuery's AJAX module, and are therefore probably the most notable feature of jQuery in recent years.

In the article I'll show not only how they can be used with AJAX (their most common haunt) but also for situations other than AJAX. I demonstrated this here a few months ago when I showed how deferreds could be used to make an interactive word game.

Attributes vs. properties

1.6 was a quieter affair; no new major features, but a handy tidy-up of how jQuery handles attributes vs. properties. Until 1.6, both had been dealt with via the attr() method. Whilst helpful, this unhelpfully gave the impression that attributes and properties were one and the same.

If you're not sure of the difference, I go into it fully in the article.

on() / off()

Of course the big arrival in 1.7 was an encapsulated approach to events. By 1.7 the events API had got pretty messy, with all sorts of methods kicking around. 1.7 introduced on() and off(). The former can be used for both direct and delegated events, such that no other method is required (previously, if you wanted to delegate, you had to look at live() or delegate()).

XMLPlayground

While we're talking about .NET, I was pleasantly alerted on Twitter today to the fact that they featured my very own XMLPlayground.com in their list of top recent tools. Happy days!

1 comments | post new

The magic of JavaScript's apply()

I recently answered a Stack Overflow question re: how to call a function in PHP with a dynamic number of arguments. The answer is call_user_func_array().

I mentioned in passing that the JS equivalent was apply(), and that apply() could also fake execution context. asked me to elaborate, so here I am.

Meet apply()

apply() is the clever gem of intermediate-advanced JavaScript, and is one of my favourite features of the language.

Inherited by every function/method, apply() has two uses, allowing you to:

• set the this context in which a particular function/method executes
• pass an array of arguments to a function that ordinarily expects each argument to be passed separately

Both of these are hugely useful and allow you to accomplish things that would otherwise require cumbersome loops or outright code re-writes.

Below I'll look at four varying use-cases for apply().

Use case 1: library APIs

Whilst 'faking' the context of a function may seem somewhat whorish at first, it can be hugely useful where libraries are concerned. Why, we need look no further than our ubiquitous friend jQuery. Consider this:

There, I select all paragraphs with text longer than 5 characters. (The filter() method, if you don't know, takes a callback function and applies it iteratively to each matched element; the element is removed from the stack if the function returns false).

But have you ever wondered why, conveniently, this inside the callback magically points to the element? There's certainly no native reason this should be so. The reason is, internally, jQuery does something like this: (Warning - guesswork ahead, but the point remains).

As you can see, the callback is not merely invoked, it is applied, with each element (in turn) set as the this context. Clever, eh? If this wasn't possible, jQuery would have to pass the element as an argument to your callback instead - decidedly less graceful. The callback is all about the element, so it's sensible this points to it, just as it does natively in, say, event callbacks bound with addEventListener().

Use case 2: array as arguments

This is easily demonstrated with some built-in methods, for example Math.min(). This method, you won't be staggered to learn, finds the minimum value from within a list of numbers passed as separate arguments.

That's fine, but the chances of you ever wanting to use this method in the above way are pretty slim. Almost always, you'd have an array of numbers, probably gathered or computed dynamically, and want to find the lowest one from within that.

Other languages, such as PHP via array_min, allow this. In JS, you'll need apply() magic:

Since our numbers there are generated dynamically, the first approach is not an option. Because apply() takes an array and passes it to a function as though each value of that array was a separate argument being passed, this is our solution.

Note that I pass null as the first argument, since Math.min() is a static method that does not care about context - it merely deals with what it is passed as arguments.

Let's look at an example where contexts is relevant.

Use case 3: an approach to inheritance

JavaScript lacks a formal notion of classes and, therefore, classical inheritance. What it does have, and what is at the centre of the language, is prototypal inheritance. Using this, there are various approaches to simulating traditional inheritance.

One of them (though not necessarily the best one) utilises apply().

As I say, this is just one approach to inheritance simulation. Like all approaches, it has advantages and disadvantages. It would be off-topic to discuss them here, but there's more info on this here. Ultimately, the approach to inheritance used comes down to taste and requirement a lot of the time.

Use case 4: Converting function arguments to array

You might think this sounds like the second use-case I demonstrated, but I'm driving at something rather different here.

Inside any function, a local variable, arguments, is implicitly created. It is an array-like object (but NOT an array) of the arguments passed to that function.

There, arguments looks and feels like a normal, indexed array - in fact it's an object, with keys named 0, 1 and 2.

A common need is to treat arguments as an array - and, happily, apply() can help us with this.

(Well, it's part of the help. The following technique also owes a lot the fact that Array's slice method is not particularly fussy about needing a real array - apparently an array-like object will do fine, also.)

Line 2 fails because push is a method of Array, not Object. We must first 'coerce' the arguments object to an array, as we do in line 3. Normally, slice() is concerned with the extraction and return of certain elements of an array, but since we don't pass it any arguments denoting this, it simply gives us back an array in its entirety.

apply() vs. call() vs. bind()

These three tend to get lumped together because they're all concerned with setting the this context in which the stipulated function runs. Let's quickly look over some of the differences.

call() works just like apply() except arguments must be passed individually, not as an array. So it has only one benefit - context setting. With this in mind, you'll probably find yourself using apply() far more than call().

bind(), on the other hand, is concerned with the creation of new functions that are permanently bound to a particular context. Contrast this with apply(), which does not create functions - it merely invokes them.

So if you wanted to make a permanent copy of a function or method, but which runs in a different context from its original, use bind().

This is best demonstrated with reference to a common error among early JavaScript developers. Perhaps armed with the knowledge that complex types are copied by reference, not value, the following does not behave as they expect:

We make a reference to the method - but the context is not stored. Therefore, when the alias is invoked, by the that time it's running in the context of the global scope, not obj.

To make the alias whilst also preserving context, bind() is needed:

(Sidenote: another capability of bind() is that you can specify default values for function arguments, a la partial application, but again that's off-topic for this post. For more on this very useful method, check out the excellent MDN documentation on it.)

And finally... apply() with instantiation

One of the minor drawbacks of apply() is that it cannot natively be used for instantiation. You might try something like this:

What we meant was to run apply() on the instantiation of the class. What actually happens, though, is JavaScript first runs Dog.apply(...) and then the result of that operation is instantiated. In short, a right mess, and not what we wanted.

Fortunately there's a couple of workarounds for this. I favour this one, demonstrated in this Stack Overflow answer:

A bonus of that snippet is it demonstrates an alternate approach to simulating classical inheritance (I mentioned there were a few ways). This approach is known as the temporary constructor approach, and utilises a blank function as a 'proxy' between the parent and child classes. As I mentioned, I won't go into these here - but there's more info on them in this article.

Conclusion

So there you have it. I told you apply() was clever. A lot of what we take for granted in library APIs depends its magic. At first the concept can seem quite shocking - faking context? Isn't that bad pattern design? - but as I've hopefully shown, there are good cases for this. And there's more - I showed only a handful.

(Icon attribution: Oxygen Icons)

5 comments | post new

REGEX round-up: two issues...

I've recently become something of an addict to answering questions on Stack Overflow. As something of a gleeful REGEX sadist, this is one of the areas I answer on.

Two questions recently highlighted again some of the inabilities in REGEX.

1. Capturing repeating sub-groups

One concerns captured sub-groups. If you're not sure what this means, take a look at this:

The result of that is an array of the following structure:

As the comment says, in most REGEX implementations if not all, the first element of the matches array is the entire match. But I also asked for a sub-match, (there), so that gets sent in as the second array element. And so on, for as many sub-matches as I specified.

This is fine, but gets tricky where you want to repeat a sub-match and capture each repetition of it separately. Consider this:

That pattern asks for "foo" followed by "bar" one or more times (since I use the "once or more" operator, +, after my sub-group). It returns this:

You can see the instruction to allow repetition of the sub-group has been honoured insofar as the pattern, in its entirety, matches. But you will also notice that it captured only one of the sub-group instances, not three.

If you're finding this a bit of a headache (and you either love REGEX or find it melts your brain), the bottom line is this:

Your matches array will contain only as many results as there are sub-groups explicitly defined in your pattern (plus the entire match as the first element).

At least in JavaScrtipt and PHP, anyway. I have seen fleeting references to functionality in other languages that can capture repeated - i.e. implied instances of - sub-groups, but I don't know for sure.

Partial workaround

As confirmed by the priceless Regular-Expressions.info, the above pattern is a common pitfall, but I include it just to illustrate the point.

A partial workaround is to capture the repeated sub-group in yet another sub-group. So:

That returns this:

...because this time I made a point of capturing not only the sub-group to be repeated, but also the cumulative result OF that repetition.

But the problem remains that we have not captured each instance separately. When I say "problem", it's not an error of R&G&X; it wasn't designed to do this. It's just an inability.

It's not a show-stopping problem. If you really want "bar" to be represented three times separately in an array, it doesn't take much to first do the REGEX then split the second array element (in our case) by the space delimiter).

2. REGEX is not a parser

Another question that I answered the other day considered the use of REGEX to parse a proprietary tag format.

This should set alarm bells ringing immediately. REGEX is not a parsing tool.

In any case the user wanted to parse the various tags from the following string. The complication is in the fact that tags may contain nested sub-tags.

A similar question came up today, asking the same thing, but with HTML. (Incidentally, REGEX is always a bad choice for parsing XML-based languages, given the DOM route).

The problem with both is this: REGEX cannot hope to reliably know which opening tags correspond to which closing tags.

Take the following HTML (based on the question I mentioned above):

Let's say you want to capture the row that contains the string "County":

Tested against our HTML, this will be the result:

This is logical when you think how REGEXP works. It begins at the start of the string, and is asked to find an opening <

tag. It is then told to allow for zero or more characters of any kind ([\s\S]up to and including the string "Forest".

(Side note: if you're wondering, I use [\s\S] rather than . because the latter, though a wildcard character, does not in fact match white-space characters, which is a big deal here as our string is multi-line, and line breaks are spacial characters. The only way to match truly anything is with the former, which literally says "get me all non-space and space characters", i.e. everything.)

This is precisely the problem. In telling it to allow any characters of any kind before the string "Forest", we actually cover from the start of the string (i.e. the first row) into the second.

In other words, our match will be from the beginning to the end of the requested row - never just the requested row.

Ideally we'd limit that first [\s\S] from matching another

A partial workaround

Let's return to the first example, with the proprietary tag format. The aim, of course, is to extract each of the three tags. This question was a PHP one, so I came up with this horror.

That actually works. The concept is to first locate and extract all tags that do not contain nested sub-tags, and then work outwards. I'll save you the laborious, line-by-line explanation, but if we print_r($matches), we get this:

post a comment