I have a lot of side projects at various phases of investigation right now. So many, in fact, that I'm quite sure that I won't get around to actually implementing even half of them. Because completed projects are more important to me than the right to say that I wrote the code, I'm going to list some of them here in the hopes that someone on the lazywebs will be inspired to do something with my vague description.
Add New Features to Clang. The Objective-C runtime (at least Apple's version of it) allows any string to be specified as the name of a class, but existing Objective-C compilers only allow letters, numbers, underscores and dollar signs in class names. I'd really love to introduce the ability to have class names with greater variety. Apple has already shown their willingness extend the Objective-C language; I'm just going one step further. Here are a few more ideas that I'd like to see in clang:
Refactor Monodevelop. Monodevelop has great support for things like syntax highlighting and code completion, but most of these features are very tightly tied to Gtk#, and if you want to access such features using a different UI framework, you're out of luck. I'd like to see Monodevelop refactored so that there is a library of common, platform-agnostic code that could conceivably be used from a variety of applications. I know I'd use it.
Write an Objective-C interop library for .NET that uses IDynamicMetaObjectProvider. Objective-C is a very dynamic language, so this sort of implementation makes quite a bit of sense. Individual Objective-C objects would likely inherit directly from SafeHandle and implement IDynamicMetaObjectProvider; all/most method invocation would happen via DynamicMetaObject. Then, using C#'s new dynamic keyword, most of the functionality in Cocoa would be accessible without the need for an enormous wrapper library.
The family members who sent us stuff through Amazon didn’t opt for gift wrap (it’s a pretty expensive option), so we have to wait for Christmas day to even know who each package is for, let alone what it is or who ordered it. Perhaps we are seeing the formation of a new holiday tradition?
During my morning journey through all that is new and noteworthy today, I ran across this article about a "killer development tool" for Linux. The author of this article claims that the tool is "going to make ISVs and other programmers start to love developing for Linux."
I must admit that my interest was piqued. I've done at least a little bit of development on each of the major platforms (Windows, Mac, various flavors of Linux), and I must say that tool support had a big effect on the pleasantness of each experience. Furthermore, while I understand that many developers are quite comfortable with Linux, the lack of a "big neon sign" saying "start here" was a big turn off for me (contrast this with Visual Studio for Windows and XCode for MacOS, and you'll begin to understand what I mean).
So what is this amazing tool? As it turns out, it's a package that helps developers find incompatibilities between their applications and various distributions of Linux.
That's a "killer" application? It's going to make me "love" developing for Linux?
Pardon my incredulity, but applying a band-aid over a problem that doesn't even exist (for the most part) on other platforms does not a killer application make. Nor will it make a person "love" developing for that platform. At the very most, one might say that it "makes the platform less painful" or "eases the burden associated with developing for the platform."
Not so much. I think I'll stick with Windows and MacOS for now, thankyouverymuch.
So today's lesson: if your "killer application" just eases the pain associated with a problem that doesn't exist in other environments, you're doing it wrong.
This is just a quick note to let you know that NSDuctTape now supports communication in both directions (i.e.-you can now instantiate and manipulate Objective C objects from .NET). The support is still rudimentary, and it's not especially robust, but it's there, and it works. Currently, the new code is only available through Subversion, but I'll probably clean it up a bit and post a new download this weekend.
There has been a lot of talk lately about the usefulness (or lack thereof) of design patterns in software, but the Model-View-Controller pattern is, without a doubt, one of my favorites. For any who are unfamiliar with it, Model-View-Controller separates the code of an application into three tiers: code that presents an interface to the user (View), code that actually does useful stuff (Model), and code that glues it all together (Controller). On many platforms, such as Apple's Cocoa or Microsoft's WPF, the view may be partially (or completely) implemented without explicitly writing any code, which can greatly speed the development process.
One under-utilized implication of the Model-View-Controller Pattern is that very careful application of the pattern allows models to be reused in multiple contexts; for example, a model might be used as the backbone of both a Windows application and a web application (or theoretically, for a Windows application and a Macintosh application; this is currently rather difficult, although I am working to make it a practical reality). However, even when the models are reused, the views and controllers must be rewritten from scratch. In the case of the view, this is often not a terrible burden, especially when there are good tools for creating views on your platform of choice. On the other hand, rewriting a controller is tedious, boring work. Most of the time, a controller does little more than shuttle data between the view and the model and occasionally disable a control or two. You'd think that there'd be an easier way to hook everything up that didn't involve so much pain and suffering.
As it turns out, you'd be right.
A number of modern MVC frameworks provide a relatively new facility known as "bindings". The UI widgets in such frameworks provide you with the opportunity to specify data sources for various properties (for example, the text in a text field or the enabled state of a button). At runtime, the widgets sign up to receive notifications when the applicable properties on their data sources change (generally using something akin to the Observer pattern). If the data source changes its value for a property, the view will automagically catch this update and change its display accordingly. Likewise, when the user changes a value in the UI, the view propagates this change down to the model.
While this ability to bind directly to a model is incredibly useful and can greatly reduce the amount of code required for many applications, it also leaves us with a question: where do we put all that code that doesn't exactly fit in a model but that also cannot be adequately represented in the view (for example, the enabled state of a button)? One answer that has been proposed is Dan Crevier's DataModel-View-ViewModel pattern. In this pattern, the model (which is renamed to the "data model") and the view remain essentially unchanged, but the controller morphs into being just another model. However, rather than modeling the underlying data, a view model keeps track of application state.
When properly designed, a view model is much more unit testable than a controller, and it seems to me that it ought to be more portable between MVC frameworks, as well. Unfortunately, this pattern comes with a practical hurdle that must be overcome: sometimes, a desired behavior cannot be adequately modeled in a way that is usable by the view. It's often tempting to use this as an excuse to bake platform specific code into a view model, but I find this to be inelegant. In such cases, a developer has two options: either new UI widgets can be created (or extended) to understand the new behaviors, or a controller may be reintroduced in order to serve as a bridge between the view model and the view.
I'm fairly certain that each of these approaches has situations in which it is the best solution, but I strongly suspect that a new controller is the best choice in the majority of cases. While this method does add a fourth tier to the system, which will increase complexity, I believe that in most cases, it will ultimately be less work than baking new functionality right into a view toolkit.
I really wish I could come up with a snappy ending for this post, but it just isn't coming, tonight. In closing, if you're not using MVC in your designs right now (or if you're using it in an undisciplined fashion), I strongly recommend that you study up on it and see if it's right for you. If you're already using MVC, but you aren't using bindings, I'd suggest that you look into whether or not your framework supports them, as they can save you from quite a bit of tedious code.