I've just uploaded a new version of MarkdownDeep with a a few tweaks pulled in from github pull requests:

1. Merged Ben Swaynes changes for the GUI editor markup and styles, as described on his blog post - http://www.benswayne.com/improving-markdowndeep-jquery-editor-markup. Thanks Ben.
2. Merged some fixes relating to footnote formatting (incorrect # prefix on element ids + missing closing angle bracket on the closing list tag).

Both sets of changes are up in github and in nuget now.

I mentioned in my previous post about building Minicomp that it took a long time to get MiniComp's application icon right. Today while cleaning up I noticed a set of SVG files that shows roughly how that went...

	First attempt, too cartoony
	I've tried this cut-out style icon a few times, but it's never really worked out.
	Borrowing the striped green look from the messages app. For a while I was considering a green lawn type theme.
	Back to a gold trophy look, but keeping the stripes.
	Back to green again (I really do have no idea what I'm doing), this time going for a simpler/cleaner look.
	I was using this grey mesh background in the app for a while (but it was bit too much). The gold look is one of the effects in Inkscape, and while it looks nice and shiny it's too lumpy around the edges for my liking.
	Getting closer, this is where I'd settled on the in-app theme of carbon fiber background with blue accents.
	This was done after the final icon below and was used briefly for the debug build of the app.
	The final icon. Carbon-fiber background, matching blue trophy and border, gloss-over effect.

I called this post "Icon Evolution" but in retrospect it was more like "Icon Trial and Error". In the end, I'm really happy with it - it just took a long time to get there.

You can see a bigger 512x512 version of the icon in the MiniComp Press Kit.

The Idea

The idea for MiniComp came about when my teenage son was telling me about a competition he and his mates were running for their school sport. They play squash once a week and wanted to run a simple leaderboard, just to make it a little more fun. The system they had was a bit flawed so I suggested using the Elo ranking algorithm (the same algorithm Zuckerberg used for FaceMash), and the idea for MiniComp sort of flowed from there.

It's pretty simple:

1. Enter the names of everyone playing.
2. Enter the results of games as you play.
3. That's it! MiniComp ranks everyone and shows a leader board.

The Proof Of Concept

As a long time fan of Mono, choosing MonoTouch as the development tool was a no brainer. I'd used MonoTouch before for some prototype work and some tiny throw away type apps and figured it would be perfect for this. And it was, the first version took just two nights to build and supported the basic idea described above as well as support for multiple competitions.

And it passed the proof of concept. My son used it for their squash round the next day and immediately they were hooked.

It was at this point I realized this app might have some potential - mainly because of just how easy it is to use and the immediate leaderboard it generates. There's no need write down results on scraps of paper, or to get back to a PC to enter results, no spreadsheets etc... it's just very convenient and the results are instant. It simply adds a new layer of fun.

As for the name? It's just something I grabbed out of thin air right at the moment I created the C# project.

A Little More Functionality

Thinking about how MiniComp might be used I realized that with a few simple options I could make it flexible enough to work with just about any game or sport.

• Scoring Mode controls whether to record actual point score results, and whether highest or lowest score wins. In most games the highest score wins, but some games it's the opposite (eg: golf). And sometimes there's just no score - it's either win/loss/draw situation, or perhaps you just couldn't be bothered entering a score.

• Ranking System controls how players are ranked. Elo is great but sometimes the most wins, or most points is a better system. It also supports a points-for-place mode where first place gets so many points, second gets so many etc...

• Two Player and Multi Player. Whether the game is played head-to-head between two players (eg: squash) or everyone plays at the same time (eg: motor racing).

Some Polish

I was now about a week in and happy with the functionality, but the UI looked a bit plain using the standard iOS controls. So I just started playing around with colors and came up with the blue on black look which made the whole thing a little more interesting.

I also tried a few variations on the background texture before settling on the "tiny carbon fiber" look that's now used through out the app and the website.

All the artwork was done in Inkscape. By picking a simple flat look, I managed to knock together all the in-app icons in practically no time. It's a minimal UI - as in minimal effort.

The main app icon was a different story altogether - this took alot of work and many iterations to get right, but worth it I think.

Total effort so far: two weeks part time.

The Server

By now, some of my son's mates were asking for copies of the results and it became obvious that the ability to publish and share the leaderboard would add another interesting dimension to it. I didn't want to spend too much time on this so the requirements were the bare minimum:

• Ability to publish a competition without any signup or registration.
• Ability to share published competitions by Twitter, Facebook and Email.
• Enough security to prevent someone hacking your published competition.
• Optional, minimal privacy by obscurity.

The server is written in ASP.NET MVC and runs on a Linode server under Mono.

Published competitions are stored in a single table database (using PetaPoco of course) with the serialized competition stored as a text blob. Because both the app and the server are written in C# all the serialization code for competitions just worked on both platforms and generating the leaderboard views was really just an excercise in HTML formatting.

Security takes the form of an authentication token that's allocated by the server when competition is published. That token is required to update an already published competition and is returned to and stored by the app.

For privacy, although everything published to the website is publicly viewable you need to know the published URL. Since thisis made up from the database record ID and the name of the competition in slug form it's pretty hard to guess. For the insensitive nature of this data it's good enough to keep things private if you want... just don't give out the URL in public.

The server and the associated changes to the app took about another week, bringing it up to 3 weeks.

The Promo Site

For the promo site I wanted something that looked slick, gave a brief overview of what the app was and then linked off to the AppStore. It's a very simple design consisting of just the one landing page, but there's a few interesting things.

• It's Responsive and a scales well from iPhone resolution all the way up to a large desktop monitor. I've not done a responsive design before and a simple site like this seemed a good way to learn the basics. Also I figured it's the kind of site that will be viewed from range of different devices and therefore worth the effort.

• It's Retina enabled. Looking at the first version of the site on my iPad 3 the screenshots and icon was noticably blurry. I thought I could use CSS media queries to do some simple image replacement, but in the end a simple JavaScript routine proved easier. I might write this up in a later post, but you can view the source and figure it out pretty easily. The site now looks super crisp even on high-res devices.

• Getting Twitter buttons and Facebook Like buttons to look good together and on a dark background is difficult. The biggest problem here was the white iFrame background that flashed behind the Like button - very distracting. I tried a number of approaches to mitigate this, but in the end just hid their containing div until they finished loading and faded them in with jQuery. The script is simple, view the source of the site if you're interested.

Aside from the promo site I also set up a Facebook page, Twitter account , and a press kit which includes marketing material, media images, a press release and more.

All up the promo site and marketing resources took about another week. 4 weeks elapsed.

Other Services

In building MiniComp I used a number of neat products and services:

TestFlight

I think anyone who's done iOS development would already be familiar with TestFlight, but for those who aren't it's a way to distribute ad-hoc builds of your app to testers. Beautifully designed, does what it says, worked perfectly.

Also, MonoDevelop has a built-in command to push to TestFlight. It's actually easier to publish to TestFlight from MonoDevelop than it is from XCode.

Flurry

I looked into a few analytics options, but decided on Flurry for two reasons - I liked the design of their site and MonoTouch already had bindings written for it.

AppAnnie

I haven't used AppAnnie much yet, but I'm confident. It's a better way to track downloads and sales figures from the AppStore. Unlike the AppStore, AppAnnie keeps your sales figures indefinitely and seems to have nicer reports and charts.

Their sign-up process is painless, their emails are friendly and helpful, I can only assume the rest of the service lives up to the hype.

prMac

prMac is a public relations outlet for Apple and Mac related news. I'm not sure how effective this will be in the long run but I've been reasonably impressed so far. For $20 they'll push out your press release to 700+ media partners. Their site also has some great of information on how to write a decent press release which I found very useful (I think you need to sign up before you can access this, but sign up is free).

MonoTouch and Mono

I've already mentioned Mono and Xamarin but they really do deserve another mention.

At the same time as developing MiniComp I was doing contact work developing another mobile app for iOS and for Android, using ObjectiveC/XCode and Java/IntelliJ. The difference between the two experiences was night and day - especially for the iOS development. I find XCode/Objective-C to be overwhelmingly infuriating and switching back to MonoDevelop after using XCode all day was a huge relief.

Since this was the first complete app I'd done with MonoTouch I was a little concerned that it might start to crack around the edges as I got more into it, but it really didn't. In fact the more I got into it the more it shone.

Conclusion

So there you have it. All up the whole project went extremely smoothly taking just 5 weeks, including a week of waiting for the the app submission/review cycle. I have no idea how it will sell, but at the very least I've learned a lot and my son has a cool app.

Interested in MiniComp? Check it out here: http://minicompapp.com.

After a very busy 2011, I took the first couple of months of 2012 off and did pretty much nothing - at least nothing to do with software development - just alot of unwinding and I feel all the better for it.

Since then I've been working on a few different projects, including new version of Cantabile, some contract work doing mobile development for iOS and Android, and more recently I've been playing with OpenGL, Mono, MonoTouch and MonoDroid with thoughts of maybe doing a mobile game (it's been along time since I did any games programming).

The question I keep getting asked however is when will there be a new version of PetaPoco? Well firstly I'm somewhat reluctant to change PetaPoco too much - simply because I want it to stay as simple as possible and well, I like it the way it is. If you were hoping to see PetaPoco grow into something bigger, more feature rich, then I'm sorry to disappoint - but that's simply missing the point of what PetaPoco is. Also since none of the projects I'm currently working on use PetaPoco it's easy to just leave well enough alone.

That said I have found some time to start on a new version - which will be called v5. Even though there's nothing major about it, I have opted for a major version number bump because it won't be drop-in backwardly compatible.

Dropping the Single C# File Approach

The first thing I've done with v5 is to forget about trying to maintain the whole thing in a single C# source file. Similarly I'm dropping the fascination with trying to keep the line count as small as possible. These ideas served well to keep PetaPoco tiny during its inception, but really serve no practical purpose moving forward.

So the project is now a separate assembly and the original PetaPoco.cs source file has been split up into a series of source files (one class/interface/enum per file) and grouped into folders - all of which means the project is much easier to navigate around and therefore easier to maintain.

But I Like a Single C# File

Although for maintenance purposes having the code base in separate source files is a great, from the point of view of using it in a project there's a certain appeal to being able to drop in a single source file and not having to worry about assembly dependencies. So, I've knocked together a tool that munges everything back into a stand-alone PetaPoco.cs file. Best of both worlds!

CSJ (for CSharp Join) is a simple command line tool which you'll find in the PetaPoco solution that can join a bunch of C# files into a single file. It works well enough for what I need for PetaPoco, but might work for other simple projects too.

CSJ is run automatically by the PetaPoco project during it's post-build phase.

XML Documentation

Because of my previous line count obsession I had been reluctant to do XML documentation comments for PetaPoco. Now that it's broken up into separate files I now feel like there's "room" for these.

The XML documentation on all the public parts of PetaPoco is now complete, however... my eyes glazed over and my brain shut-down as I did it - there could be some weird comments in there.

New Mapper API

Turning PetaPoco into an assembly has some ramifications - particularly in relation to the static Database.Mapper property. As an assembly, there's the possibility of it being used by two other assemblies at the same time and if both wanted to register type mappers it would be a case of last in best dressed.

So the old Database.Mapper property has been removed and replaced with a new Mappers class through which IMapper's can be registered - associating a mapper with either a specific POCO type, or for all the types in an assembly.

Aside from how they're registered the IMapper interface has also had a bit of clean up and PetaPoco's automatic built-in mapping is now implemented as a mapper itself. See the IMapper interface for more on this.

ForceToUtc Changes

This feature was always a bit of hack. Some DB providers return date time values with a DateTimeKind of Unknown. The ForceToUtc option simply changes the returned values from Unkown to DateTimeKind.Utc - without actually changing the date value.

In PetaPoco 4, this was an option on the Database class - now it's an attribute of the POCO property. eg: Column[ForceToUtc = true]

Another important change... ForceToUtc used to be true by default, now it's false.

Renaming Things

As mentioned above, some things have been renamed for consistency:

PrimaryKeyAttribute properties:

• Value -> PrimaryKey
• sequenceName -> SequenceName
• autoIncrement -> AutoIncrement

TableNameAttribute properties:

• Value -> TableName

Tuples for Dictionary Keys

In PetaPoco v4 I was lazy with keying the internal dictionaries that PetaPoco uses. Instead of declaring key objects and writing to associated Hash calculations I just dumped all the key values into a string and used that as a key. With later versions of the runtime an easier (and I presume faster) approach is to use Tuples - which is what PetaPoco now does.

The downside to this is that PetaPoco now requires .NET 4.0. To get it running on earlier versions should just require re-implementing some compatible Tuple classes, but I just haven't got around to it yet.

Other Internal Changes

Internally, PetaPoco has also had a bit of rework/refactor/cleanup:

• The old DBType property has been replaced with an abstract DatabaseType class that provides database engine specific functionality. Old if this database do this else do that type code has been replaced with calls to the DatabaseType class. (See the DatabaseTypes folder in the solution for more on these)

• There's a new Cache classe that simplifies the caching of various objects within PetaPoco.

• Lots of other minor bits and pieces.

Pull Requests Merged

At this point, the main functional changes are the following pull requests that have now been merged:

• Replace column names that conflict with CSharp keywords automatically
• Add Page override to support user defined SQL for Count and Paging
• Fix for issue #91 - Template was selecting the clustered index, not the primary key.
• Check connection state prior to Open() to avoid error: System.InvalidOperation
• Change rxOrderBy Regex and logic to be less greedy during Page query rewrite to support sub-select ordering
• Add IsNew() Support for PK of Type Guid
• Fix: ensure the primary key value is returned from Insert() when the primary key column is not an autoincrement.
• Fix for Issue #81
• Speeded up mapping with types containing enums.
• Added fix for uint columns in SQLite
• Allow Nullable T in ExecuteScalar
• Fix for crash which would occur when trying to save more than 4000 characters into a SQLServerCE NText column

(Tip: if you want to see something fixed in PetaPoco, your best chance is to submit a pull request).

Upgrade CheckList

Here's a quick check list of things to consider/remember if upgrading from PetaPoco 4 to 5.

1. If you need pre .NET 4 support, abort now. (or write some tuple classes as described above)
2. Get the latest version from GitHub on the v5 (not master) branch
3. Decide on whether you prefer the Assembly or Single Source File version of PetaPoco.
   • If you want the assembly version you'll need to build the PetaPoco project in the supplied solution. Remove PetaPoco.cs from your existing project and add the assembly reference.
   • If you want to continue using the Single Source File, just copy the new PetaPoco.cs over the old one.
4. If you're using custom mappers, you'll need to switch from assiging the Database.Mapper property to calling Mappers.Register().
5. You might get build errors on some attribute properties that have been renamed. Typically these are just upper/lower case issues and should be easily fixed.
6. If you're using ForceToUtc option, be warned. You'll need to explicitly decorate all DateTime Columns with the appropriate attribute or, write a custom mapper to do it.
7. Cross your fingers :)

Availability

All of this is available in a new 'v5' branch on GitHub, but shouldn't be considered production quality. Feel free to grab it and give it a go and let me know what you think, but more importantly what's broken. Once I'm confident that it's stable I'll put up a new build to Nuget.

What's this about an iOS Game?

Yes, I've been doing some iOS game development. Nothing too fancy, but certainly fun - I might post some info about this soon.

As you may have noticed I haven't posted anything here for a while - primarily because development of Prefix has been suspended. There's a couple of reasons for this, but the main two are:

1. We've decided to cease operations at the company where I work my day job. Commencing 2012 I'll be officially out of work and looking for something new to do.
2. Given that I can't figure out how to commercialize Prefix, it needs to be put on the back-burner to make room for something that will pay the bills.

I'd like to return to Prefix at some stage but for the moment at least it's shelved. Besides Prefix I also have several other unpublished projects which have also been suspended - the slate needs to be cleared.

Having said all that, this seems to be the perfect opportunity to look for something completely different to work on. So over the coming month(s) I think I'll try my hand at various random things to see what piques my interest. Perhaps something in the mobile space, maybe some game development, perhaps something else. Who knows?

This post is about Prefix - a modern language that compiles to JavaScript. A language where C# is the inspiration - not the goal. Read more on the Prefix Project Page.

Prefix has had for loops pretty much since day one. I'd deliberately left out foreach loops until now because I wanted to integrate them with some sort of enumerable/generator (eg: IEnumerable<T>) mechanism, but I've decided to put that off for now and just aim for parity with JavaScript functionality.

Enumerating Array Like Objects

First up, the Prefix foreach statement will work with any type that implements a int length variable or property and an indexer that takes an integer parameter - including obviously arrays and strings.

Prefix uses a temporary variable as the counter and just enumerates the collection as you'd expect:

extern dynamic Console;

var x = new string[];
x.push("Hello");
x.push("World");

foreach (var i in x)
{
    Console.WriteLine(i);
}

(function() {

// Start Global Code
var $temp;
var x=[];
x.push("Hello");
x.push("World");
for ($temp=0; $temp<x.length; $temp++)
{
    var i = x[$temp];
    Console.WriteLine(i);
}

})();

The generated code will use an additional temporary variable if the expression begin enumerated might cause side effects. In this example, $temp2 is used to hold the array to avoid multiple calls into fn:

extern dynamic Console;

string[] fn()
{
    var x = new string[];
    x.push("Hello");
    x.push("World");
    return x;
}

foreach (var i in fn())
{
    Console.WriteLine(i);
}

(function() {

function fn()
{
    var x=[];
    x.push("Hello");
    x.push("World");
    return x;
};

// Start Global Code
var $temp, $temp2;
for ($temp=0, $temp2=fn(); $temp<$temp2.length; $temp++)
{
    var i = $temp2[$temp];
    Console.WriteLine(i);
}

})();

(in case you're wondering, Prefix tracks temporary variable allocations and re-uses them, so multiple consecutive loops like this will declare the temporary variables once at the top of the scope (function) and re-use them multiple times over).

Enumerating Dictionaries

I've always thought object enumeration in JavaScript to be a little messy - though I do understand the reasons for it. In JavaScript there's two main reasons for enumerating an object - to get all the values of a associative array, or to enumerate all the methods, properties, fields of an object (say to dump/inspect it). The differences with these two approaches relates to whether to enumerate the prototype chain or not.

The JavaScript for...in statement does enumerate the prototype chain. If you only want the immediate properties of the object (say the keys of a dictionary) you need to use the hasOwnProperty method to detect the items to exclude.

In Prefix, the call to hasOwnProperty is included automatically in generated foreach loops.

(In the following example I'm using backtick escapes to declare literal JavaScript - to better show the object layout).

extern dynamic Console;

// Purposely put something that doesn't belong in the object prototype
// This SHOULD NOT appear in the output
`Object.prototype.somecrap = 23`;

// Create a dictionary
var dict = `{apple:1, pear:2, banana:3}`;

// Dump the contents of the dictionary
foreach (var i in dict)
{
    Console.WriteLine(i);
}

(function() {

// Start Global Code
Object.prototype.somecrap = 23;
var dict={apple:1, pear:2, banana:3};
for (var i in dict)
{
    if (!dict.hasOwnProperty(i))
        continue;
    Console.WriteLine(i);
}

})();

Enumerating Object Members

The above example raises the obvious question of how to enumerate the entire prototype chain? Well, with a new form of the foreach statement: foreach member (var i in whatever).

The following example is the same as the above but I've added the member pseudo-keyword:

extern dynamic Console;

// Purposely put something that doesn't belong in the object prototype
// This SHOULD appear in the output
`Object.prototype.somecrap = 23`;

// Create a dictionary
var dict = `{apple:1, pear:2, banana:3}`;

// Dump all members of the dictionary (including the extra property in the object prototype)
foreach member (var i in dict)
{
    Console.WriteLine(i);
}

(function() {

// Start Global Code
Object.prototype.somecrap = 23;
var dict={apple:1, pear:2, banana:3};
for (var i in dict)
{
    Console.WriteLine(i);
}

})();

The member modifier can also be used on arrays to enumerate the actual members of the array instead of just the items in the array.

Conclusion

That's all for the foreach statement for the moment. I do intend on addition support for something like IEnumerable<T> and yield return but not just yet...

If you've been using the experimental build of Prefix, I haven't updated it with this functionality yet - I'll post something when I do.

This post is about Prefix - a modern language that compiles to JavaScript. A language where C# is the inspiration - not the goal. Read more on the Prefix Project Page.

A delegate type lets you declare the required prototype of function and pass references to matching functions around. What we need now is an easier way to declare these functions inline - without having to create an actual "function" per se.

Anonymous Functions

An anonymous function is a function declared without a name and with an inferred return type. It's declared using the delegate keyword as part of an expression. Consider the following where an unnamed ("anonymous") function is passed to a another function:

extern dynamic Console;

void DoSomething(Func<int, int> cb)
{
    Console.WriteLine(cb(10));
}

DoSomething(delegate(int x) { return x*88; });

(function() {

function DoSomething(cb)
{
    Console.WriteLine(cb(10));
};

// Start Global Code
DoSomething(function(x) {
    return x*88;
});

})();

Because anonymous functions don't declare a return type, the compiler must be able to infer it from usage. (in the above example it's infered from DoSomething's cb parameter which is declared as Func<int, int>

Lambda Expressions

Lambda expressions are an even more concise way of writing an anonymous function that directly returns the result of a single expression. The syntax for lambda expressions is based around the => operator and prefix supports the same syntax formats as C#. eg:

• ()=>99 - a lambda expression with no parameters
• x=>x*2 - a lambda expression with a single untyped parameter
• (x,y)=>x*y - a lambda expression with multiple untyped parameters
• (int x, int y)=>x*y - a lambda expression with multiple typed parameters

A lambda expression is equivalent to a anonymous function that simply returns a value. So this:

(int x, int y) => x * y

is equivalent to:

delegate(int x, int y) { return x * y; }

Note too that with lambda expressions (unlike anonymous functions) you don't have to specify type arguments for the parameters - they're inferred in the same way the return type is.

Solving the this/that Conundrum

In JavaScript when nesting one function inside another, the inner function doesn't inherit the this reference from the outer function. In order to reference the outer class the developer must manually setup a that reference in the enclosing closure. (see here for a better explanation).

The Prefix compiler however has enough type information to know how to set this up automatically. So if an anonymous function inside a class method refers to a member variable of the outer class, this is automatically stored in a local variable $this and the nested function automatically uses it.

Here's an example showing both a lambda expression and the use of $this:

extern dynamic Console;

class MyClass
{
    public int Value;
    public void DoSomething(int input)
    {
        Func<int, int> fn = x=>Value * x;
        Console.WriteLine(fn(input));
    }
}

var x = new MyClass();
x.Value = 23;
x.DoSomething(10);

(function() {

// class MyClass
var MyClass = function() {};
MyClass.typeName = 'MyClass';
MyClass.prototype.Value = 0;

MyClass.prototype.DoSomething = function(input)
{
    var $this = this;
    var fn=function(x) { return $this.Value*x; };
    Console.WriteLine(fn(input));
};

// Start Global Code
var x=new MyClass();
x.Value = 23;
x.DoSomething(10);

})();

Generic Type Inference

All that's left to do in this area is type inference of generic function arguments from lambda's and anonymous functions - coming soon!

This post is about Prefix - a modern language that compiles to JavaScript. A language where C# is the inspiration - not the goal. Read more on the Prefix Project Page.

I've always thought JavaScript's runtime type support to be rather lame - not so much in what it can provide, but simply that it's rather inconsistent. For example, using typeof on any custom class/object simply yields "object". Great - not.

In Prefix I wanted to improve this situation a little and provide something a little more reliable. Prefix has two type inspection operators:

typeof

returns the constructor of an object or value

typename

returns a descriptive name for an object type

Both operators can accept either an object instance, or a compile type type name.

For the built in types (boolean, string etc...), typeof returns the boxed object constructor (eg: String.constructor) while typename returns the equivalent of the JavaScript typeof operator (eg: "string", "boolean", "number" etc....)

For Prefix classes, including generic classes typeof returns the class function and typename returns a descriptive name of the class - with generic arguments substituted. eg:

extern dynamic Console;

class Bar
{
}

class MyClass<T>
{
    public void fn()
    {
        Console.WriteLine(typename(T));
    }
}

new MyClass<bool>().fn();
new MyClass<int>().fn();
new MyClass<Bar>().fn();
new MyClass<MyClass<int>>().fn();
Console.WriteLine(typename(MyClass<int>));

boolean
number
Bar
MyClass<>[number]
MyClass<>[number]

Note that although Prefix distinguished between int and double at compile time, there is no such distinction at runtime - hence the appearance number in the resulting typename.

There are a couple of runtime helper functions to support these operators but as always they're tiny, automatically generated by the compiler and only generated when actually needed.

(Don't forget Prefix also supports runtime type querying via the is and as keywords).

This post is about Prefix a modern language that compiles to JavaScript. A language where C# is the inspiration - not the goal. Read more on the Prefix Project Page.

Burst Fish is a tutorial game written by Seb Lee-Delisle that I found on the excellent creativejs.com site. The original tutorial can be found here http://creativejs.com/tutorials/create-an-ipad-optimised-game/.

I thought this would be an excellent project to port to Prefix as both an example project and as a first experiment to see how Prefix works in the real world. Aside from one missing piece of functionality and a few bugs in the compiler itself, porting it went remarkably well. Here it is:

• View the Game in your Browser (You'll need a webkit based browser - Chrome or Safari)
• Download the Source

(Please note I haven't released Prefix yet so although you can look at the source you can't compile it yourself yet. If you're interested in trying the compiler ping me on Twitter or email me).

To show how the Prefix code looks, here's an extract of the Emitter class used to generate the exploding fish particles:

// Emitted is used to generate the explosion particles
class Emitter
{
    // Constructor
    public Emitter(dynamic domContainer)
    {
        this.domContainer = domContainer;
    }

    // Fields
    private dynamic domContainer;
    private Particle[] _particles = new Particle[];
    private Particle[] _spareParticles = new Particle[];

    // Called by main game loop to update particules
    public void update()
    {
        for (var i=0; i<_particles.length; i++)
        {
            var particle = _particles[i]; 
            if (!particle.update())
            {
                _spareParticles.push(particle);
            }
        }
    }

    // Make an explosion at specified position
    public void makeExplosion(double xpos, double ypos, double zpos)
    {
        // Just create bunch of particles
        for (var i=0; i<30; i++)
        {
            var particle = makeParticle();
            particle.init(xpos, ypos, zpos);
            particle.update(); 
        }
    }

    // Make a particle by initializing a new one, or by grabbing one from 
    // the spare list
    private Particle makeParticle()
    {
        Particle particle;
        if (_spareParticles.length>0)
        {
            particle = _spareParticles.shift();
        }
        else
        {
            particle = new Particle(domContainer); 
            _particles.push(particle); 
        }

        return particle; 
    }

}

// class Emitter
var Emitter = function()
{
    this._particles = [];
    this._spareParticles = [];
};
Emitter.typeName = 'Emitter';
Emitter.prototype.domContainer = null;
Emitter.prototype._particles = null;
Emitter.prototype._spareParticles = null;

Emitter.prototype.ctor$1 = function(domContainer)
{
    Emitter.call(this);
    this.domContainer = domContainer;
    return this;
};

Emitter.prototype.update = function()
{
    for (var i=0; i<this._particles.length; i++)
    {
        var particle=this._particles[i];
        if (!particle.update())
        {
            this._spareParticles.push(particle);
        }
    }
};

Emitter.prototype.makeExplosion = function(xpos, ypos, zpos)
{
    for (var i=0; i<30; i++)
    {
        var particle=this.makeParticle();
        particle.init(xpos, ypos, zpos);
        particle.update();
    }
};

Emitter.prototype.makeParticle = function()
{
    var particle;
    if (this._spareParticles.length>0)
    {
        particle = this._spareParticles.shift();
    }
    else
    {
        particle = (new Particle().ctor$1(this.domContainer));
        this._particles.push(particle);
    }
    return particle;
};

The game works as well as the original and although there are a few bits in the generated code that could be cleaned up, as a first attempt I'm fairly pleased with it.

This post is about Prefix a modern language that compiles to JavaScript. A language where C# is the inspiration - not the goal. Read more on the Prefix Project Page.

"First-class Functions" are one of those topics that most new programmers struggle with - it's a weird concept passing a function to another function, or storing it in a variable. In JavaScript however this is a fairly common practice and the Prefix equivalent is a delegate.

Simple Delegates

A delegate type declaration gives a name to a function prototype ie: the set of parameters to a function and its return type. Once a delegate type is declared you can create variables or parameters of that type and store or pass function references in them.

eg:

extern dynamic Console;

// This is the delegate type - it specifies that functions
// references by it must have a single integer paramter and
// a void return type
delegate void delDoSomethingWithInt(int a);

// Here's a function that satisfies that requirement
void PrintInt(int x)
{
    Console.WriteLine(x.toString());
}

// Create a variable and store a reference to the function in it
delDoSomethingWithInt fn = PrintInt;

// Call it
fn(5);

(function() {

function PrintInt(x)
{
    Console.WriteLine(x.toString());
};

// Start Global Code
var fn=PrintInt;
fn(5);

})();

Note that in the generated JavaScript all references to the delegate type vanish - however they've served there purpose in letting the compiler check that only matching functions are passed. For example if the PrintInt function accepted a different set of parameters an error would be generated.

Binding Delegates to an Object Reference

In the above example, the function called is a simple global scope function. Delegates however can reference a function on a specific object instance. In this case, Prefix binds the object reference so that it's passed to the function correctly when it's invoked:

extern dynamic Console;

class MyClass
{
    public int Value;
    public void DoSomething()
    {
        Console.WriteLine("MyClass.DoSomething - " + Value.toString());
    }
}

delegate void del();

var inst = new MyClass();
inst.Value=23;

del fn = inst.DoSomething;
fn();

(function() {

// Prefix runtime library
var $dex = {};
$dex.bind=function(a,b){var c=a[b];return function(){c.apply(a,arguments)}} 

// class MyClass
var MyClass = function() {};
MyClass.typeName = 'MyClass';
MyClass.prototype.Value = 0;

MyClass.prototype.DoSomething = function()
{
    Console.WriteLine("MyClass.DoSomething - " + this.Value.toString());
};

// Start Global Code
var inst=new MyClass();
inst.Value = 23;
var fn=$dex.bind(inst, "DoSomething");
fn();

})();

Note that calling the delegate variable fn knows nothing of the MyClass instance, yet calling it still works thanks to the binding done by the helper function $dex.bind.

Generic Delegates

Prefix also supports generic delegates. Consider this example which is identical to the previous example except that the delegate is declared as a generic. The int parameter type isn't resolved until the delegate is used:

extern dynamic Console;

class MyClass
{
    public int Value;
    public void DoSomething(int param)
    {
        Console.WriteLine("MyClass.DoSomething - " + Value.toString() + " - " + param.toString());
    }
}

delegate void del<T>(T a);

var inst = new MyClass();
inst.Value=23;

del<int> fn = inst.DoSomething;
fn(5);

(function() {

// Prefix runtime library
var $dex = {};
$dex.bind=function(a,b){var c=a[b];return function(){c.apply(a,arguments)}} 

// class MyClass
var MyClass = function() {};
MyClass.typeName = 'MyClass';
MyClass.prototype.Value = 0;

MyClass.prototype.DoSomething = function(param)
{
    Console.WriteLine("MyClass.DoSomething - " + this.Value.toString() + " - " + param.toString());
};

// Start Global Code
var inst=new MyClass();
inst.Value = 23;
var fn=$dex.bind(inst, "DoSomething");
fn(5);

})();

Func and Action

Now that Prefix has support for generic delegates, support for Func and Action are simply a matter of declaring them:

delegate TResult Func<TResult>();
delegate TResult Func<T1, TResult>(T1 p1);
delegate TResult Func<T1, T2, TResult>(T1 p1, T2 p2);
// etc...

delegate void Action();
delegate void Action<T1>(T1 p1);
delegate void Action<T1, T2>(T1 p1, T2 p2);
// etc...

Prefix includes built-in declarations for Func and Action with up to 8 parameters:

extern dynamic Console;


int addem(int a, int b)
{
    return a+b;
}

Func<int, int, int> op = addem;

Console.WriteLine(op(10, 20).toString());

(function() {

function addem(a, b)
{
    return a + b;
};

// Start Global Code
var op=addem;
Console.WriteLine(op(10, 20).toString());

})();

Type Inference with Delegates

Prefix supports generic type inference with delegates. The following example declares a generic function with two generic parameters TIn and TOut. Note that when the function is called, it's simply called fn and the type are inferred from the usage. ie: Prefix has inferred that TIn is int and TOut is string.

extern dynamic Console;

TOut fn<TIn, TOut>(Func<TIn,TOut> cb, TIn input)
{
    return cb(input);
}

string convert(int val)
{   
    return val.toString();
}

Console.WriteLine(fn(convert, 23));

(function() {

function fn$2(cb, input)
{
    return cb(input);
};

function convert(val)
{
    return val.toString();
};

// Start Global Code
Console.WriteLine(fn$2(convert, 23));

})();

Conclusion

Delegates are an important concept for Prefix as they bring the language considerably closer to JavaScript's capabilities and also lead into Lambda's and Anonymous Functions which I'm working on now.