popp crop

POPP Diary #4 - The First Submission

A short one this week. As I get deeper into the work, it’s beginning to take over from any attempt to write about it. However, I did encounter some features which are new since the last edition. Before I get to that though. I delivered my first chapter!

Chapter Three

Chapter Three is an introduction, running from ‘what is an object?’ through to inheritance. It’s an important chapter for those new to object-oriented programming, but achingly familiar to anyone who has picked up a textbook on the subject before. It’s all the more important as a writer, therefore not to skimp, to keep it as fresh as possible. I try to conjure up the days I was teaching myself Java and getting in a constant tangle about the difference between a class and an object. So I focus quite a lot on that early on. I enjoy my analogy of a rubber duck machine, with the mold as the class and the churned out ducks as object instances of the class.

Finally, the all the tools work paid off somewhat and saved me loads of time towards the end when it came time to renumber and re-import listings.

Book Production with Git

I was able to get my process geek hat on when it came to working out what might work best for collaboration. The chapter needs to receive both editorial and technical reviews. Now that we’ve gone plain text, the next problem is – how do we manage threaded annotations. That’s easy in Google Docs and Word, of course – not so much in a Markdown file. In the end what seems to make sense is to use a git platform – the usual suspects being Github, Gitlab and Bitbucket.

The work is already on Bitbucket, so I started there. I made a feature branch for Chapter Three and then issued a pull request – the idea being that reviewers could leave messages there. However, the thing about a pull request is that it shows a diff between the main branch and the feature branch. Since Chapter Three already existed on the main branch, the PR only showed some fragmentary changes. Clearly the answer is to remove the chapter entirely from the main branch and add it fresh to the feature branch. That worked nicely – but with a couple of pretty hefty problems.

Firstly, it seems that Bitbucket does not give you the option of wrapping long lines in its diffs. The only advice I could find from them was to introduce hard coded newlines. Easy enough (that’s what the command line fold tool is for after all), but I’d rather not do it.

Secondly, and more importantly, Bitbucket refused to show the chapter because it was too long. That was game over.

Both problems went away in Github, so I shifted there. Incidentally, if you’re ever wanting to move from Bitbucket to Github, I recommend this guide – it made the process a no-brainer.

Some new features

Much of the work of the chapter was minor – lots of refreshed tests, tweaked language, updated information. There were a few new features since last week however.

Property type declarations are not new – but they are new to POPP. It’s not world-shattering, but it’s nice to enhance type safety and improve readability by declaring the type of properties – like this:

class Point
{
    public int $x;
    public int $y;
}

And actually it makes it feasible to create some simple classes with public properties where before you’d have to use accessor methods to constrain type.

Union types are nice too:

function setPercentage(int|float $percent)
{

}

At first, I thought that the mixed type – a version in code of the virtual type used in PHP documentation for arguments and return values – was a little redundant. After all, everything is always already mixed unless otherwise declared. However, signalling that a property, argument, or return value is mixed removes ambiguity.

Also new to POPP are nullable types:

function addPoint(? Point $point)
{

}

The question mark here relaxes the type declaration – addPoint() can accept Point or null. It is equivalent to:

function addPoint(Point|null $point)
{

}

And on to…

Chapter Four next. It’s a monster – with over a hundred code examples – all needing checking and updating.