Elegant Chaos

Last weekend QPR started off our league campaign with a 4-0 victory over Barnsley. Whilst the result was a bit flattering (two of the goals were penalties, and Barnsley were rubbish), it was hard to complain with a start like that. We ended the day top of the league on goal difference.

Fast forward three days and we played Port Vale in the League Cup. Despite them being two levels below us in the league structure, they comprehensively beat us 3-1.

I was more disappointed with the team selection than the ultimate result of this game. We made quite a few changes from Saturday's team, and although some of them were necessitated by international call-ups, not all of them were.

We gave every impression that we were "concentrating on the league" - ie not taking the cup seriously.

WTF? Hello? We're QPR. We're in the Championship. We're not Barcelona, snowed under by Champion's League fixtures and World Club Cup malarky! And anyway, it's the first week of the season!

It seems to me to be pretty poor psychology to pick a weakened team for cup games, especially coming off the back of a good victory. It puts the fans in a negative mood. Let's face it, football fans are never happier than when in a negative mood (perverse and perhaps even oxymoronic, but true). They love nothing better than having a bit of a whinge.

When we pick a weakened team, they have the perfect excuse, especially if it results in a defeat to opposition who we clearly ought to be beating. We pay our money and turn up on a wet Tuesday, and in return we get to see some players who the manager probably doesn't rate, or who are too young and inexperienced for the first team at this point. Occasionally they impress, and a new legend is born, but more often than not they display all of the qualities (or rather, all the lack of qualities) that the manager saw in them, and which placed them into the reserves in the first place - and so the fans get on their case.

Knocking the confidence of players who are struggling for form is bad enough, but of course some of the players who played on Tuesday were first team players, some of them playing only their first or second game for their new club, and they got tarnished by a bad performance too.

Before you know it you've got a few idiots in the crowd who've convinced themselves that someone is rubbish on the basis of one performance in a bad team. That sort of thing rubs off on players, turning it into a self-fulfilling prophecy. In extreme cases, it can complete bugger up a players career at a club.

So like I said, bad psychology from the manager!

Surely, so early in the season, it's better to maintain momentum and pick your strongest team. Apart from anything else, they need more pitch time together, and they need that mercurial match fitness that only playing regularly gives them. This has got to be even more true when you've got six or seven new players in the team who barely know each other.

And surely we're not worrying about them playing too many matches at this stage? If they can't cope with an extra game now, we're going to be in big trouble in the spring!

I have one theory about all this. Neil Warnock knows that we need some better players, so he deliberately chose a team on Tuesday that would illustrate the weakness of our squad to the board. If true, I'd say that part one of the cunning plan worked - we clearly do need some better players. Whether part two - the buying of said players - will follow, it remains to be seen.

Whether or not this theory is true, I still think that the danger of some of our better players suffering collateral damage as a side effect is real, and wasn't worth the risk.

Oh, and of course, I'm pissed off that a wasted a couple of hours of my life on a wet Tuesday!

I've just finished reading my first novel on the iPad.

There was a certain irony in my choice of material - Singularity Sky, by Charles Stross - as I'd already read half of it as a paperback on holiday a while ago, only to be scuppered when I turned from page 138 and found myself on page 203.

Yes, it turns out that paper books can have bugs in them too! In my case the book had been mis-bound causing a sizeable chunk of the middle section to have been replaced by a copy of another sizeable chunk! Much swearing ensued…

Anyway, that was the paper version - what of the iPad? Overall I found the experience quite favourable.

I'd read a few technical documents already using iBooks, which is pretty functional. The display is great (though an iPhone 4 style retina display would be even nicer), and even reading documentation outside in the park is very manageable.

I'd wondered though whether I'd get tired or feel awkward reading fiction on the thing, late at night or for extended periods of time. Apparently not! Despite it being a bit heavy, the iPad is no worse than a large hardback, and reading in bed was fine. Reading on the train was easier too - other than generating a few interested glances from fellow passengers - since it's considerably slimmer and easier to fit into my bag. The only thing I missed was reading in the bath!

Regarding software, as it turned out, I didn't use iBooks, I used the iPad version of the Kindle application instead - which has pretty much the same interface.

My choice of the Kindle app reflects my only real criticism of Apple in the iPad experience so far, which is that the UK book store is absolutely rubbish. I can only assume that this is down to a failure to negotiate licensing deals. The upshot seems to be that if you want to read something that isn't on the best seller lists, you're out of luck. Science fiction? I think not, unless it's so popular that I've already read it…

Luckily, Amazon, whilst still not having anything like universal eBook coverage, nevertheless has a much better selection, and the Kindle application is at least as functional as iBooks.

Overall conclusions? Much as I like paper books, I'm sold on the iPad as a reading experience. I have approximately 1000 paperbacks and a couple of hundred hardbacks on my shelves at home, and they don't half take up a lot of room. One or two are special, but the vast majority are cheap paperbacks, bought second hand, with no intrinsic sentimental value above and beyond their contents. At this stage in my life, the opportunity to do one of my favourite things (reading), without adding more clutter to an already too cluttered existence, feels highly attractive!

Lazy Properties

There was one other motivation for thinking about all of the Objective-C property stuff: Lazy Initialisation.

Lazy Initialisation is a GoodThing™, especially in the iOS world where memory is tight, and performance isn't always stellar.

So why the bloody hell didn't Apple add a lazy attribute to the property system, so that you could do this:

@property (retain, nonatomic, lazy) id foo;

In my world, that would synthesise a getter which performs a lazy initialisation the first time it's called, by calling a standard method (called fooLazyInit or something similar).

It seems to me that this would be a great boon to iOS developers. To some extent it also gets round the instance variable vs setter problem for the init method - the answer becomes simply not to initialise the property at that point.

All of this stuff has been mulling around in my brain for a while, so I was thinking, would it be possible to add some more property macros to my existing ones, like so:

ECPropertyDeclareLazy(name, type, attribute);
ECPropertySynthesizeLazy(name);

The answer is yes, it's a bit tricky, but it is possible, and here's how.

Implementing Lazy Properties

My main consideration was that I didn't want the macro to have to write all the proper getters and setters, since that would mean losing all of the retain/copy/nonatomic goodness that @property gives us (or recreating it in the macros).

So the trick is to wrap the generated getter with one that checks if the instance variable is nil. If it is, it initialises it directly by calling a special initialiser method. It then just calls on to the generated getter.

The solution I came up with looks like this to use:

@interface MyClass
{
    ECPropertyDefineVariable(foo, id);
}

ECPropertyDefineLazy(foo, id, retain, nonatomic);
@end

@implementation MyClass
ECPropertySynthesizeLazy(foo, setFoo, id);

- (id) fooInitLazy
{
    return [[[SomeClass alloc] init] autorelease];
}

@end

If you don't care about backwards compatibility with the old runtime, you can get rid of the ECPropertyDefineVariable bit.

The ECPropertyDefineLazy macro is defined like this:

#define ECPropertyDefineLazy(name, type, ...)       \
    @property (__VA_ARGS__) type name##Lazy; \
    @property (__VA_ARGS__) type name; \
    - (type) name##LazyInit

Here we actually declare two properties - one called foo, the other fooLazy. We're going to let Objective-C synthesise fooLazy for us, so we get the right retain behaviour etc.

We also forward declare our fooLazyInit method here. It's not strictly necessary, and we don't actually want anyone calling it, but it allows the actual implementation of the method to appear anywhere in the .m file, which is more convenient.

The ECPropertySynthesizeLazy macro is defined like this:

#define ECPropertySynthesizeLazy(name, setter, type)    \
    @synthesize name##Lazy = _##name; \
    - (type) name { if (!_##name) self.name##Lazy = [self name##LazyInit]; return   self.name##Lazy; } \
    - (void) setter: (type) value { self.name##Lazy = value; }

We let Objective-C synthesise the fooLazy method, but we ask it to use the foo instance variable. This isn't strictly necessary (it doesn't really matter what the variable is called), but it makes it consistent with the other property macros, and means that if you do try to access the instance variable directly it will be there and be called what you were expecting.

We then manually implement the getter and setter for the actual foo property.

The setter just calls on to the synthesised version. Annoyingly we have to pass in the name to use for this, since we can't automatically turn foo into setFoo as it involves turns "f" into "F" in a macro. We also have to pass in the type of the property to the synthesize macro, since it needs it to declare our getter and setter methods. In an ideal world it could work this out for itself.

The getter checks the instance variable directly to see if it's nil. If so, it calls fooLazyInit to get a value, and assigns it to the synthesised property. From then on, we just call on to that property to return a value.

To maintain the correct semantics for the property, we assign the result of the fooLazyInit method to the synthesised property using its setter. We could just set the instance variable directly, but that might not be atomic when it was supposed to be.

Assigning to the instance variable directly might also break the retain/assign/copy behaviour, so it's safer to go through the setter. To stick to the standard naming conventions, fooLazyInit should really autorelease any object that it allocates. This isn't ideal from an efficiency point of view, but it is cleaner. It allows us to call on to the synthesised setter and have it call retain if it's supposed to. Bear in mind that fooLazyInit is perfectly allowed to return an existing instance, so this isn't an irrelevance - we need to be certain that the retain/release semantics of fooLazyInit will always be consistent.

So What's The Point Of All This

Essentially, the point is that I've now got a relatively easy, and totally consistent, way of declaring properties to be lazy initialised.

There is a performance penalty, of course - since we have to check the instance variable.

If used wisely though, that's weighed against the performance gain achieved by not bothering to initialise properties until they're needed - which may be never.

It also means that you can clear properties more aggressively in response to low memory situations. You don't have to worry so much about the consequences when you know that the property will get created again on demand.

These macros are pretty new, and might turn out to be a complete cul-de-sac, but I'm going to give them a go.

If you want to try them out as well, I'll upload them to github: http://github.com/samdeane/code-snippets/tree/master/objective-c/properties/