So as you can probably figure out by looking around on my blog, I'm working quite a bit in Netwire recently. I put one of my posts, netwire-pong... Pong in Netwire (duh) on /r/haskell. I presented some qualms I had with the Netwire library. In response some people gave me some advice regarding the organization of Netwire applications. I've been pondering their responses for a couple of days, and I think I'm ready to publish something on it.

netwire-pong as Reference

Abstraction. Seriously. When writing my netwire-pong game, I wasn't thinking about this. I was trying to get things working, without really thinking about how I should get them working. That bit me in the bum later on, as is mentioned in the article. In hind-sight, now clear thanks to the people over on reddit, I shouldn't be passing around so much information. The ball, to perform collision and scoring required:

The render size.

The left paddle.

The right paddle.

I'm passing everything my ball could collide with. Every single thing. In this case, it's only three, but in a large application, that's a lot more. Think of a game with hundreds of entities. Do I want to pass them all to something that might collide with them? Of course not. Thanks to comments from /u/mstrlu and others, I realized the better way is to just tell the ball when it has collided. Even handling the scoring (which is just returning a value telling the game if it should increment either of the scores) could be done externally relative to the ball.

This is a simple case, but defines a precedent for future use. Pass on and return the minimal amount of information you need to. Thereby making the Wires modular and easily composable.

Going Onward