I've been waiting for a pause after the release of Beta2 to ask the community for help in understanding the potential role of the trait reserved keyword.

While F# excels in many areas, (IMHO) object design is somewhat difficult. I don't have vast experience here, my domain being mainly mathematical in nature, but occasionally I've needed to break a class down into smaller compositional pieces and have found that the lack of implicit interfaces or multiple inheritance has required me to rewrite client code or manually write forwarding members on the refactored classes. I can imagine that for larger class hierarchies this becomes painful.

I do understand the reason behind enforcing explicit interfaces and tend to agree with the design - however having a finer-grained mechanism that allowed rapid, safe and compositional object design would be a great victory for the language.

My current reference for trait design is Nierstrasz and Co. 2005, which states:

Traits are essentially groups of methods that serve as building blocks for classes and are primitive units of code reuse. As such, they allow one to factor out common behavior and form an intermediate level of abstraction between single methods and complete classes. A trait consists of provided methods that implement its behavior, and of required methods that parameterize the provided behavior. Traits do not specify any instance variables, and the methods provided by traits never directly access instance variables. Instead, required methods can be mapped to state when the trait is used by a class.

In many cases modules and combinators reduce the need for this 'intermediate level of abstraction', but in the case of large, stateful (though not necessarily mutable) objects a fluent mechanism of composition is required.

Traits can be simulated in CLR languages using a combination of interface properties and interface method extensions. It's the responsibility of a class that 'inherits' a trait to implement the fields required by the trait's property interface, but then inherits all the trait's functionality (courtesy of the trait's interface extension methods.) This separation is the key to avoiding the notorious diamond problem.

I've pasted below a simple implementation of Circle example in the introduction to the Nierstrasz paper. As you can see it's rather ungainly. Could the trait keyword help here? What further concerns am I missing? Are there better ideas for implementation of the keyword / the concept? How do traits compare to mixin's?

All answers much appreciated,

Danny

open System

type Extension = System.Runtime.CompilerServices.ExtensionAttribute


type ICircle =
    abstract Centre : float * float
    abstract Radius : float


[<AutoOpen; Extension>]
module ICircleExtensions =


    type ICircle with

        member x.Area    = 2. * Math.PI * x.Radius

        member x.Bounds  =
            let r = x.Radius
            let x, y = x.Centre
            (x - r, y - r), ( x + r, y + r)

    [<Extension>]
    let Area(x:ICircle) = x.Area


    [<Extension>]
    let Bounds(x:ICircle) = x.Bounds

type IDrawing =
    abstract Bounds : (float * float) * (float * float)

[<AutoOpen; Extension>]
module IDrawingExtensions =


    type IDrawing with
        member x.Draw() =
            printfn "Draw on Bounds of %A" x.Bounds

    [<Extension>]
    let Draw(x:IDrawing) = x.Draw()


type Circle(centreX: float, centreY:float, radius: float) =

    interface ICircle with
        member x.Centre = (centreX, centreY)
        member x.Radius = radius

    interface IDrawing with
        member x.Bounds = (x :> ICircle).Bounds

[<AutoOpen>]
module CircleExtensions =
    type Circle with
        member x.ICircle    = (x :> ICircle)
        member x.IDrawing   = (x :> IDrawing)

[<AutoOpen>]
module Main =
    let c = Circle( 100., 100., 200. )
    do c.IDrawing.Draw()

    Console.ReadKey() |> ignore