Six to Eight supports all the Stack Exchange sites in the network. You “subscribe” to the sites you’re interested in, optionally focusing your attention on one person by “tracking” them. As such, the first view seen by new users of Six to Eight will be one requiring them to setup an initial subscription. You might think this should be easy, and perhaps it should be. However, for me, it turned into one of the most complex pieces of design and development in the app.

This “Subscription creation” view, which also allows them to edit existing subscriptions, has to accomplish three things:

1. Let users pick a Stack Exchange site
2. Let users decide if they want to track somebody, and allow them to pick that person
3. Just get out of the way as quickly as possible for users who just want to play with the app

Users have also got to be able to experiment with this setup a bit. If they’re tracking a user on one SE site, and want to switch to another, it’d be annoying if they had to re-select that user (assuming that the user is also using the newly selected site).

Let’s have a look at my UI attempt (see on Vimeo):

The UI uses a normal iPhone table view to present the site list, and user tracking toggle. This will, hopefully, present a large number of sites in an familiar fashion. The user selector allows people to easily find their own user within the selected site, and the re-association function saves them from having to repeat this task when they experiment. The UI is nearly all non-modal, so users can change their minds and toggle options without needing to wait for data. Importantly, if they just want to close the UI and start playing, they need only wait for the sites list to load, then tap “Save”.

So, to the implementation. For what looks like it should be a reasonably simple presentation of data, the code that runs this view is the most complex in the entire app. This is mostly to do with the number of possible states the UI can be in, coupled with the desire to keep things happening in an asynchronous fashion – lots of background work is occurring to update the data and verify it whilst the user selects their options.

Initially, the view turns up in a “Loading” state – there are no sites known, no user selected. We can’t do anything until we know what sites exist in the StackExchange network. This information comes from the StackAuth API endpoint at http://stackauth.com/1.0/sites, and Six to Eight fetchs it via my CoreStack CSAuth class. We request the data, and place the UI into a “Loading” state whilst we wait for it to arrive. Once our delegate is called to indicate that the CoreStack background loader has the data, we can update the UI with it, and transition into a “Select a site” state, where we default to the first available site and to tracking no user.

The entire UI is stitched together from this type of state transition, so we might as well represent it as a finite state transition diagram. In this…

1. Grey indicates the UI is fully operational to the user
2. Red indicates an error state, with suitable modal error message
3. Blue indicates a modal state, where the UI is displaying a “Working” dialog (like the “Look for John Doe on SESite”).
4. Green indicate “complete” states, where you can return having created a new subscription
5. Purple indicate other view controllers
6. Solid arrows are state transitions activated by the user
7. Dashed arrows are state transitions activated by the controller

The goal is to start in the left hand purple state (where site subscriptions are listed), and get back there via one of the green states. For clarity, I’ve omitted all the “Cancel” links back to the Site selector state – all grey and green states can get there.

Moreover, these are not all the possible states of the view controller, only the UI. Internally, the view controller can be both not waiting for or waiting for data from the Stack Exchange API, including the sites list, user check data, and site icons. This isn’t even all the UI – this is just the core view (and even then, excluding each “Waiting for icon” state). The slide down user selector has it’s own internal UI state, and is activated from the two grey states in the centre of the diagram.

In all states other than blue, the UI is responsive to user interaction. Ideally, there would be no blue states, however in v1.0, I had no time to expand the state management to feasibly handle the feedback and changes needed to make user checking and re-association non-modal.

From the perspective of the API, re-association is easy. Whenever we start to track a user, the user selector dialog returns a structure obtained from the API endpoint api.sesite.example.com/1.0/users/filter?SEARCH, (CSUserDescription from CoreStack) that indicates the user name, their identifier and an association GUID. This association identifier is unique across all accounts tied together in the Stack Exchange network. When the user toggles the selected site, if we have such an association GUID, we display a modal dialog whilst we use the stackauth.com/1.0/users/GUID/associated method to find all the sites this user has associated themselves with. We search this list for the newly selected site, and either fail to find it (and so disable user tracking and display an error), or we find it and update the tracking data. The modal display is then hidden.

So, how did I do with respect to the 3 point goals initially set above, and the more general goals set out in part one?

As shown by the lack of solid arrows in the diagram between the two states and the first green state, the user can get a site up and running by just waiting a few seconds then pressing “Save”. This will setup the first reporting Stack Exchange site from the StackAuth API, without tracking a user. Similarly, the user is in control of the UI in all non-blue states, which represent the vast majority of interaction time with the UI. They can can cancel the setup, or change their settings. I think this “super fast initial setup” and responsive UI are key points in creating a good app.

The re-association feature is another subtle but important consideration for a touch based UI. We could leave it out, and whenever a user who’s tracking someone changes site, they could just re-search for their user. However, this requires more fiddly typing and network access – both best avoided on the iPhone. The StackAuth re-association API lets us save them the effort. Despite the fact that this feature is, in truth, rarely going to be used, I think the extra effort was well worth it. The fact that the Stack Exchange API allowed it with reasonable ease is testament to the quality of the feedback/design process used by the Valued Associated over at Stack Overflow Inc.

Now, if you’ll excuse me, I’m going to re-associate with an ale.

They’ve recently release a JSON based API for accessing their sites, and as an avid Stack Overflow user and Apple fan, I’ve wanted a pocket client for ages. Thus, Six to Eight was born. It’s my first “Release quality” iOS development, and I thought some people might like to know how it went – both other Stack Exchange API users, and other iPhone developers.

I set out to provide a good quality application. One that felt at home on my iPhone, was useful, and provided a good foundation on which I can build in the future. As such, I focused on 4 key developmental areas:

Core functionality: It might seem obvious, but way too many apps are little more than web browsers without a decent set of browser controls. With Six to Eight, the two key ideas are “Your Stack Exchange, in your pocket” and “Your Stack Exchange user, in your pocket”. I’ve tried to design an app that provides those things in a fast and iPhone consistent experience. Everything should feel like it belongs on the iPhone – iOS like UI idioms, user input via taps, most input data being derived automatically. Users also expect a certain level of polish, which I hope I’ve delivered.

Network error handling and recovery: Coding for the iPhone, you’ve got to be ready to handle, at any time, the loss of network connectivity or the degradation of network performance to that of a 14.4k modem. Just finished parts 1 and 2 of a critical 3 part request? You can bet on a decent number of your users losing their connection just then. Six to Eight underwent a lot of testing to ensure it remaines usable even on a GPRS connection, handles network drops gracefully, and reports them to the user as best it can.

Asynchronous UI: Blocking your UI whilst you wait for data is a cardinal sin. It makes your app feel unresponsive, and renders it unusable on a slow connection. Six to Eight performs all data collection and processing in the background, streaming it into the UI as it arrives. This way, you get to see what’s been downloaded so far, without waiting for every request to complete. You can also cancel any request you’re bored of waiting for.

State preservation: iPhone apps are often asked to quit with no notice, for inbound phone calls or because the user pressed “Home”. I tried to ensure that whenever you quit, both data and UI state are persisted so you reload back to the same state you left from.

Six to Eight is approximately 14,000 lines of code. Of course, this measure by itself is useless – but how much of this code is devoted to each part of the application is, to me, interesting. The following percentages are just my estimates based on how much time each feature took and the rough code footprint, as one can’t easily untangle the mix of the above ideas.

Core functionality: 40%. Less than half the program is needed to provide the functionality I wanted. This includes talking to the Stack Exchange API, processing the data, presenting it in the UI and responding the UI events. If I was programming for a desktop machine with a guaranteed fast network connection, I could have basically stopped here at around 5000 lines.

Error handling and recovery: 10%. This includes propagating errors around the system, presenting them to the user, and designing the UI so it can present partial data where missing data is in an error state.

Asynchronous UI: 25%. This includes designing the UI as a state machine that can present data incrementally no matter what order it arrives in, as well as the concurrent download and processing of data from the Stack Exchange API.

State preservation: 25%. This includes the ability to serialise and de-serialise all forms of Stack Exchange data and the state of each view within the UI.

In my next post, I’ll talk about one part of the core functionality I rather like, from both the Stack Exchange API and iPhone development perspectives.

1. Perhaps, during the beta, they want code written in C (and derivatives) to aid in debugging framework bugs. Rather than “My App doesn’t WORK!!!!! (Using MonoTouch Vxxyy)”, they can get a repro using a stack they know and control top to bottom. In this case, I can see it as justified.
2. If it’s specifically to target cross-compilers as a business decision, to ensure that iPhone only gets “exclusives”, then I suppose it’s their prerogative. It will probably backfire long-term, as their market share isn’t that dominant. “Browser, Palm, Android + all else” or “iPhone” makes the iPhone a secondary port target versus a first class platform.

Gruber gives a third, pretty sensible conclusion – that they just don’t want to hand control of their platform to another vendor, and become a commodity target – just another checkbox inside Flash alongside “Web” and “Android”. If developers started using these meta development tools, all of the iPhones advantages vanish – it’s just another smartphone that runs Flash based applications.

For Apple the platform holder, this makes sense. For developers, any of the reasons are overly restrictive. This is, at best, ethically dubious without inconveniencing real development (which is all going on in Objective C already). At worst, it’s indicative of an ongoing schizophrenic pathology within Apple management where, despite winning ongoing customers through applications, they are happy to slap developers around just to see how far they can go before everyone decamps to Android.

We already exist with the capricious Application Review policy whereby you’re playing Russian Roulette with your development time – there’s no way to know that tell which perfectly innocent development choice will lead to rejection. Add this new restriction, and one has to wonder what choice made today will be retrospectively banned tomorrow. It’s an odd strategy, as there are plenty of innovative developers who are now scared of targeting the platform, whilst coding sweat shops keep flooding the channel with $0.10 an hour developer dross; developers who will use whatever they’re paid to use, be it Objective C or Flash. Pump enough stuff in, and some of it leaks through.

I can take two solaces from this personally. First, it literally can’t ever sensibly apply to OS X – the historical baggage makes this kind of restrictive move possible only on the closed and dominant iPhone platform. Even if they ever decided to make a “Mac App Store”, there would always have to be a standard development path lest they lose the thousands of platform portable apps that they current have (and really, OS X is still missing large swathes of desktop software that Windows has). Second, it makes my Objective C skills more valuable.

I still think it’s a poor move technically and ethically, but the iPhone platform has always been rife with these land-mines. Whether it turns out to be a good move from a business perspective, the market and time will tell.

I mentioned that Expression Blend is not a free product, but he’s mentions that “A basic version of the tooling for WP7 (including Blend) will always be free”, which is good news – the XAML designer in Visual Studio frankly sucks, and having to pay for a UI designer would be unwelcome. The main point of our brief exchange has been the (lack of) quality of Apple’s documentation, which I entirely agree with. The Interface Builder techniques I used in my implementations are not widely known, being documented in an obscure corner of the IB Manual, and it’s understandable that someone just arriving on the platform would think they didn’t exist. It’s also undeniably true that the iPhone tutorials are more complex than they need be to achieve the target application.

To clarify my opinion on this, I believe the tutorials are not going for the “ideal” MoveMe application – they’re covering a gamut of techniques people will need whilst developing for iPhone. Is the pacing of the tutorials quite right? Would a more “drag and drop” IB approach in the first few be preferable? I don’t know. Given the number of applications in the App Store, it certainly seems most people are getting to grips with iPhone development. Though given the quality of most of them, it’s fair to say there’s scope for improvement.

As before, the example rather falls over by being a comparison of “iPhone Best Practice Tutorial” versus “Ad-hoc implementation”. As I mentioned previously, the Apple tutorial series are designed to showcase development concepts, not necessarily the fastest way to achieve the goal of the sample application. This should not be read as saying the post is bad – it’s an interesting comparison in the differing development philosophy of WP7, wherein the majority of MoveMe can be created declaratively in XAML. Cocoa doesn’t have a similar UI DSL, and one can’t deny the power of the Blend/WPF combination; it made the example trivial. It is, however, probably fair to point out that Expression Blend is not part of Visual Studio (RRP $599), and that UIKit, Interface Builder and Core Animation make this specific task pretty simple on the iPhone as well.

It’s claimed that WP7 needs 5 (6 with a correction), versus more than 100 for the iPhone. We’re not going to beat 6 (typed) lines of code, but we can do a lot better than the claimed 100. By using a custom UIButton configured in Interface Builder along with Core Animation’s implicit property animations, we can achieve the result in 20 lines – with most of the work going into building the bounce animation. If we didn’t want the bounce, 8 lines would do the job. In the following, the only typed lines were the bodies of the functions and the #import statement for QuartzCore. Interface Builder generated the event handler stubs, instance variables and hooked up all the events for us.

#import <QuartzCore /QuartzCore.h>
#import "MoveMeViewController.h"

@implementation moveMeViewController

- (IBAction)touchDown:(id)sender {
    [UIView beginAnimations:@"scale" context:nil];
    button.transform = CGAffineTransformScale(CGAffineTransformIdentity, 1.1f, 1.1f);
    [UIView commitAnimations];
}

- (IBAction)touchUp:(id)sender {
    CAKeyframeAnimation *bounceAnimation = [CAKeyframeAnimation animationWithKeyPath:@"position"];

    CGMutablePathRef thePath = CGPathCreateMutable();
    CGPathMoveToPoint(thePath, NULL, button.center.x, button.center.y);

    int overrun = 10;
    CGPoint pos = button.center;

    while (overrun--) {
        pos.x = [self view].center.x + (overrun % 2  ? 1 : -1) * (pos.x - [self view].center.x) * overrun / 10.0;
        pos.y = [self view].center.y + (overrun % 2  ? 1 : -1) * (pos.y - [self view].center.y) * overrun / 10.0;

        CGPathAddLineToPoint(thePath, NULL, pos.x, pos.y);
	}

    bounceAnimation.path = thePath;
    bounceAnimation.duration = 1.5;

    CGPathRelease(thePath);

    [UIView beginAnimations:@"scale" context:nil];
    button.transform = CGAffineTransformIdentity;
    [[button layer] addAnimation:bounceAnimation forKey:nil];
    [UIView commitAnimations];

    button.center = [self view].center;
}

- (IBAction)touchDrag:(UIControl*)c withEvent:(UIEvent*)event {
    button.center = [[[event allTouches] anyObject] locationInView:nil];
}

@end

The WP7 development magic here is really in Expression Blend – creating the XAML by hand would be around 60 lines of XML. I’m not a XAML expert, but examining the provided code, there’s no specific entry for “Bounce” – the effect seems to be being created by a combination of translations and easing functions. Creating it by hand would, I’d wager, be pretty tough – as hard as it was for me to write the above simple code. Therefore, what we really lack on the iPhone side is a tool or version of Interface Builder that obviates the need for the “bounce” code above. Of course, the code hacked together for the above could be factored into a category on UIView (similar to .net Extension methods) that adds “Animate with fancy effects” method. We could then, on any UIView, call something like

  [button addAnimationFromPoint:a toPoint:b withEffect:BounceEffect];

So, again, the developmental legwork difference for this example isn’t as large as was suggested. To specifically correct the list of concepts that one needs to code by hand on the iPhone:

1. Drawing Images: No need, Interface Builder will set this up for us.
2. Drawing Text: Again, handled by IB.
3. Handling touch events: Nope, both created and hooked up via IB.
4. Creating animations: Yes, we need to indicate we want animations in the code.
5. Scaling animations: No – comes for free with CA’s implicit animation system.
6. Building a path and animating along that: Yes, and this is a pain in the neck.

I suppose it’s hard to argue that in some sense, the WP7 development was not “easier”, certainly for a novice or graphical designer. For an experienced developer, especially one who writes suitably reusable code, I’d argue that it’s pretty much a wash.

Edit: Dear me, I’m truly awful at missing “not” from my writing – For those who read the previous version, let me make it clear I was not saying the post was bad, nor was I saying the WP7 development was harder than the iPhone.

Note beforehand that I’m not disputing the power of WPF and C#. Given the choice of C# of Objective C, I’d probably rather work with C#. However, these types of language/API comparisons are rarely useful, nearly always mistaken, and correcting the record seemed an interesting task.

The first problem is that the title is inaccurate – it’s “iPhone SDK Hello World Tutorial vs ad-hoc implementation in WP7 SDK”. To show this, he goes through the tutorial and shows the same result prepared in WP7, with the banner claim being “4 lines of Code for Windows Phone 7, 44 for iPhone”. This is, at best, disingenuous. In the following video, I make the iPhone “Hello World” application using exactly the same number of typed lines of code as Shawn’s blog post. It’s not monumentally fascinating, but might show some Interface Builder features that are not widely known.

He makes two other points I’ll call out before exploring why he might make these mistakes.

“I was surprised that the User Interface Designer in XCode doesn’t automatically create instance variables for me and wire them up to the corresponding elements”

As shown, you can have Interface Builder create instance variables you need them. Regarding the automatic generation of instance variables, this is, I suppose, a matter of opinion – but years of Windows Forms programming has taught me that automated generation of instance variables for all UI elements is a nightmare. Your namespace is cluttered with dozens of instances you never need to reference and just add noise to your code.

“10% of the code, 1 file instead of 4, it’s just much simpler”

As shown, the amount of code you have to write it identical. 1 file instead of 4 is just wrong – if you download his sample program, there are 2 XAML files and 2 C# files. Counting the NIB file and main.m files as part of the iPhone solution, there are 6. So it’s 4 vs 6 in terms of files in the project, but identical in terms of the number of files you need to edit (1 XAML and C# vs 1 NIB and M file).

Why make the errors?

Shawn based his comparison on the Apple Tutorial. Why doesn’t the iPhone “Hello World” tutorial do it my way? Because Apple tutorials teach you the “Apple way” of development; “Best practice iPhone development”, if you will. Cocoa is, for better or worse, as much a philosophy as an API. If you don’t buy into the MVC approach, if you don’t structure your code in a Cocoa friendly way, you’ll be able to develop – but you’ll find it painful. As in it’s products, Apple tries to guide developers into the “right” mindset. Therefore, a fairer comparison would have been “iPhone Hello World vs Best practice WP7 Hello World”.

This is not to say there aren’t real missing features from the iPhone development environment compared to the new Windows 7 setup. Largely, this is down to Apple being conservative with the runtime features they provide for the iPhone OS. Partially, they’re feeling their way as they go. More importantly, they’ve been working on relatively limited hardware. The latest iPhone OS still supports the original iPhone, which had only a 412Mhz ARM CPU with 128Mb of RAM. Windows 7 will mandate a minimum of an ARMv7 Cortex/Scorpion with 256Mb RAM, giving the OS and application runtime a minimum of twice the memory and compute resource to play with.

If we compare against Cocoa/Objective C for OS 10.6, we see a lot of features that are waiting to be ported to the iPhone: Blocks (i.e. lambda functions for C), garbage collection, and API improvements. Given the ever progressing iPhone hardware (and new iPad), I’m expecting these shiny developer tools for iPhone 4.0 – personally, I’m voting for blocks, though a lot of people would prefer garbage collection). I’m also expecting Apple to keep forward porting Application Kit features that are currently missing – Cocoa bindings being the big one. With these, Interface Builder for OS X can build the “Hello World” desktop app without ever writing a single line of code (in fact, by typing only “Hello World” and “Hello” at the keyboard).

As a cross platform developer, I’ll continue reading the series with interest. I do hope, however, for rather fairer comparisons in the future.

EDIT: Woops, first version claimed there are, in fact, no missing features in iPhone development. Now clear that I’m not under RDF influence.

We can see the raw triangles in 3D, and we’d like to get this down to a set of lines in 2D (we can draw lines very easily using the APIs available to us). To accomplish our goal, we’ll need to think about what we actually want to see on the map – showing the floor, and little lumps and bumps is not really useful information for people. The only real obstructions that they’ll want to see mapped are the extents of the dungeon – the walls.

How can we distinguish a wall from the geometry? Well, the distinguishing fact I used in my simple algorithm was that it’s vertical – everything within a certain tolerance of the vertical axis is a “wall”, and would appear on the map.

On this diagram, we see the tolerance region – all polygons that are upright enough to be contained within the triangle are going on the map. Let’s remove everything that’s outside the verticality acceptance region, and see what we’ve got left.

Not bad – everything remaining looks pretty damn wall like to me. All we’ve now to do is turn this into a set of lines, discard the vertical components, and we have a reasonable 2D representation of the dungeon block we can use to map.

That’s pretty much it for Magellan 2 – once these line blocks are collected, they’re simply transformed (by some simple mathematics) to deal with the translation and rotation of the dungeon relative to the current viewpoint of your character. Rendering them to the screen is just a case of taking each line, transforming it, and then telling Decal “draw this line starting here and ending here”.

There are plenty of problems with this approach (some of which manifested themselves in the released version); however, this explains the basic concept (which was all I set out to do). One day, if there’s interest, I might write about these design faults, and the potential improvements that could be made.

Last time, we left off having made a series of educated guesses about how the dungeon system in AC works. From our observations, we’ve noted that every dungeon seems to be laid out in a giant 3d grid of cubes – assembled as if from lego bricks, prefabricated elements of dungeon.

We can see the prototypical dungeon template above – each little cube is ready to be filled with a one of a choice of dungeon blocks by an eager designer. A template block might look as follows.

This one is taken from my Asherons’s Call 2 archives (so don’t go looking for it in game), but it illustrates the point. The player walks around on the interior (the complex looking set of triangles), and the rest of the cube is filled with virtual nothingness – in this fashion, we can make our big cubes look like caves, temples, whatever is needed (rather than a boring apartment block).

We could take four of the above dungeon elements (that we call dungeon cells), rotate them around and put them into adjoining cubes in the template to create a donut dungeon – a giant loop. Obviously, it’s up to the designer to ensure that there’s no corridor or tunnel that leads into an unfilled cube (and hence into the void).

This is all well and good, but now that we’ve made a plausible (and in this case, rather educated) guess at the dungeon structure, how does it help us? Our task is to draw a map of the walls of the dungeon, not big wireframe meshes stuck around the place! So, tune in next time to see a little bit of simple mathematics that will transform the above into something more useful for our purposes.

The main function of Magellan 2 was as a dungeon mapping system – it would automatically generate real-time wireframe overviews of any dungeon as you walked around it. There’s nothing particularly amazing about it; indeed, retrospectively, a lot of how it worked was naive at best and bad at worst. However, a lot of people seemed to like it, and I still get about an email a fortnight asking for source code & technical information. So far, I’ve been sending out the code about once every 3 months, to give each person a chance to repair the code and publish something, alas to no avail. Hence, I figure it’s time to publish something more general and see what people can create.

Now, Magellan 2 did more than just map dungeons but the additional functionality (place search etc) is pretty trivial data management and nothing we’re interested in. We’ll be focusing on the map generation, but I’m not going to write this as a detailed set of technical specifications – more as a journey of creation suitable for all who are interested. Hopefully the information contained within, plus additional downloadable material will give people everything they need to recreate the work, if they want to.

Phase One : The problem

What we want: To create a client integrated real time usable map display of any dungeon a player wanders into, something that will help them both find their way around and allow them to explore the full depth of the dungeon (no more missed turns!).

What we we know: We have two data files, “cell.dat” and “portal.dat”, which form an archive of many thousands of smaller files. We also have some vague idea of how the AC client software deals with the problem – we know that when we enter a new dungeon, some data is downloaded and the “cell.dat” file gets larger. We also know, from our many years of dungeon crawling, that dungeons are very “modular” in design – they seem to be built out of standard components, reused many times within the dungeons.

What we can do: We can read the files contained in the cell.dat and portal.dat archive files. We can also, via Decal, draw onto the players screen, and find out their location and orientation in the world.

The challenge is set! Over the next few articles, we’ll see what we can create.

    public class CallByFuture<T>
    {
        public delegate T CallResult();

        public static implicit operator T(CallByFuture<T> instance)
        {
            return instance.Result();
        }

        public static T operator ~(CallByFuture<T> instance)
        {
            return instance.Result();
        }

        private System.Threading.Thread workerThread;
        private T result;

        public CallByFuture(CallResult func)
        {
            workerThread = new System.Threading.Thread(delegate(object state) {
                ((CallByFuture<T>)state).result = func();
            });

            workerThread.Start(this);
        }

        public T Result()
        {
            workerThread.Join();

            return result;
        }
    }

The implementation has tried to stay as close to the design goals as possible; we have a generic class, parameterised by the return type of a delegate which the user will create (either implicitly through an existing function, or explicitly with an anonymous method). The construction spins up a thread which evaluates this delegate, and gives the result back to the enclosing CallByFuture class to be made public via a Result method which will block until the answer is available. For syntactic sugar, we allow the unary bitwise NOT operator as a shortcut to the Result method (so rather than a call to the result type T expressed by the CallByFuture being t.Result().Foo, we have simply (~t).Blah.

The use of operator~ as an “easy conversion” might seem rather strange – after all, the language supports explicit type conversion operators natively. It does not, however, support having both an implicit and explicit conversion operators for the same type; the people who actually read the code will have noticed the implicit conversion snuck in at the top of the class.

The implicit conversion is very useful – it allows you to use a CallByFuture in most cases you want a T without any additional syntax. However. I would personally probably flag its inclusion as “controversial ” in a code review mainly due to the excessive “magic” behind the conversion of complex types – an innocuous usage of a variable might entail a complex evaluation behind the scene (rather than the virtual no-op of just reference passing you were expecting) – it might even throw an exception. In our case, the worst that can happen is that it must wait until the result is evaluated (any exceptions will be thrown on the CallByFuture thread, and we’ll discuss them later). Total worst case, the evaluation locks because the CallByFuture delegate never completes.

Our implementation rules stated we wanted something we could “drop in” to existing programs, and the implicit conversion certainly aids in that so next time, we’ll look at mitigating the problems it raises as well as some usage examples to prove this really does work.

[Edit: Woops - forgot to actually include operator~]