Code Crafter

In the last months, I've been developing in my spare time a proof-of-concept post-compiler with Mono.Cecil to enable roles in C# : NRoles . Roles are high level constructs that enable better code reuse through easier composition. They are very similar to traits as described in the traits paper (pdf) . Set up NRoles is hosted on google code . You can get the latest source code with this mercurial command: hg clone https://code.google.com/p/nroles/ nroles You can also download the latest binary package from the downloads page . To set up a Visual Studio project to use NRoles, unzip the binary package (or compile from source) in a folder accessible to the project. I normally have a project root folder, with folders for the project code ( src ) and for any used libraries ( lib ). For example: src\ project files ... lib\ nroles-v0.1.2-bin\ NRoles.dll nutate.exe other NRoles binaries ... In the project, add a reference to the NRoles.dll ...

After seeing what roles in C# might look like, let's see the necessary transformations that would enable them. This is one possibility that a C# compiler could use to implement roles without having to make changes to the underlying CLR. Roles A role is transformed into a set of types: an interface (which the compositions will implement), a static class with the role code, and a class that encapsulates the role state. The interface for the role is the most important type and it will carry the role name. Because all the generated types are related, they'll be packaged together as nested types inside the role interface. Nesting types inside an interface is not supported in C#, but is supported by the underlying CIL. So we'll be looking at some invalid C# along the way; just think of it as "decompiled" CIL. Let's see these transformations for a simple role: role RPrintableWithCount { int count = 0; public void Print() { Console.WriteLine(...

Traits (pdf) are described as composable units of behavior, and are a natural evolutionary path for languages like C# or Java. Microsoft must be seriously looking at them, since it's sponsored some research about Traits in C# (pdf) . I'll describe what I think is an extension to the traits idea that would make a great feature in C# (and in Java, VB.NET, ...): roles. Roles are already a reality in Perl 5, with the Moose::Roles module. They even have their own syntax in Perl 6 . They help create better organized and reusable code, are an effective and safer alternative to multiple inheritance, and have explicit semantics (which means no surprises) as opposed to mixins. What I'll describe here is based on the theoretical traits (as described in the traits paper), on Perl roles and on Scala traits , all adapted to C#. A role is, like a class, a type that holds behavior and state. It can be composed into a type (either a class, a struct or another role) to make its memb...

Scala is a very feature-rich language built on top of the JVM (there's also a version on the CLR , but the focus is clearly on the JVM). Besides its functional features, it introduces a number of constructs that facilitate large scale components development and code reuse. Scala has traits, which are a great tool for orthogonal code reuse. In its simplest form, a trait can be used just like an interface, with only abstract members, defining a contract that derived types must fulfill. It can also have concrete members, including properties and fields. Classes (and traits) can inherit from multiple traits ("inherit" is the wrong term here, better ones are "use" or "mix in"), and gain all their capabilities. Traits enable a kind of composition that doesn't rely on the structure imposed by a multiple inheritance relationship. It's more suitable for combining a target class with the roles that it performs, which should not be part of its inhe...