dsyme
commented
6 years ago I'll come clean and say I do not like this feature. If it is part of .NET interopabliity we may have to consume it, but I have little appetite to surface it directly in the F# language.
I recorded some of my feedback here: https://github.com/dotnet/csharplang/issues/288#issuecomment-288114545, copied below.
I have a bit to say about trait programming in general from the F# perspective - since this feature is really a .NET feature and the F# programmer will be exposed to functionality implemented as traits. The POV may also be useful to C# programmers.
The basic idea of traits is “Traits as a unit of composition” with “required” and “provided” methods. As mentioned in the paper Neal linked, the intention is that “required” methods are parameters, in turn “provided” by other traits or the final class.
"A trait requires a set of methods that serve as parameters for the provided behaviour"
I first want to mention that the technique “encoding parameters as required methods” is anathema In F#. In F#, parameters are parameters, much more so than in C#. I can’t emphasize that strongly enough so I’ll put it in bold again :) In the F# language design we work very, very hard to make sure parameters are just parameters :) :) This has many advantages and some disadvantages.
That is, in F# you almost never encode a parameter as an unfulfilled abstract method within a hierarchy. I’ve think I’ve seen that done like 3 times in my entire F# programming life.
That is, in F# you don’t do this:
[<AbstractClass>]
type C() =
abstract SomeParameterMethod : int -> int /// this is not how we do it
…Instead in F# you almost always write something like this:
type C(someParameterFunction: int -> int) = // this is how we do it….
…In F# you instantiate the parameter function when creating the object:
let c = C(someParameterFunction = someLambda)A further example is in a comment below.
To be honest, this approach generally turns out to be
- simpler
- lighter
- less circular/tangled
- more easily unit-testable
- basically more orthogonal with the other skills the F# developer already has.
Crucially, the focus in F# OO is not at all on “hierarchies of types” – the F# programmer almost never thinks about “the class hierarchy” (which is mentioned often in that linked paper). That’s a very, very good thing and central to the productivity benefits of F#. Java/C# programmers who don't understand this tend to produce bad F# code and/or generally don't grok why F# is asking them to forget/unlearn/disavow/repent what they have spent so long learning. Hierarchy-oriented thinking is “horrible OO” and is the kind of thinking we really want people to avoid in F#. (I think it’s fair to say that C# very much eschews “hierarchy-oriented thinking” relative to Java - and I do fear a little that adding default interface implementations to C# might change that - but that’s up to the C# designers to decide)
Importantly, if a function parameter is encoded as a true function parameter – as in F# - then it need never be revealed, so need not appear in the “surface area” of the type at all, apart from the (internal) constructor. This encourages the F# programmer to make simple things from relatively complex compositions. As described in my book (plug! plug! buy it now!) Expert F# 4.0, making simple things from complex compositions in a key technique that F# encourages.
In the world of traits, from the F# perspective it would be ideal if traits were commonly authored in a way where F# use them to capture some of this spirit. That is a C# trait declared as
interface IMyTrait1 {
abstract SomeParameterFunction(int x, int y);
member SomeProvidedMethod() => SomeParameterFunction(3) + SomeParameterFunction(4)
}declared in C# might be usable in F# as if it had been declared like this:
type IMyTrait1(someParameterFunction) =
override SomeProvidedMethod() = someParameterFunction(3) + someParameterFunction(4)
…And used like this:
type CompositionClass() =
inherit MyTrait1(fun x -> x + 1)In the example, MyTrait1 would still at runtime presumably be encoded as an interface with one implementation method and one required abstract-internal method (possibly with a compiler-generated name if declared in F#, derived from the parameter name), fulfilled by the given parameter lambda in the class. So I'm not saying the .NET/CLR mechanism has to be different.
The downside to the F# approach is that “wiring” between mutually-referential traits must be done explicitly. But mutually referential traits are, I think, relatively rare, and frankly deserve to be wired explicitly.
I guess that highlights the other thing I dislike about mixin-style traits: the names of the “parameter methods” are part of the APIs of the types. Sure, they can be given a unique name, and made assembly internal, but that’s a lot of extra keywords and a basically very odd and contorted way to declare what is really just a parameter.
Anyway, from the F# perspective it would be awesome if traits were declared so that parameter “required” methods were easily distinguished from published “provided” methods, and the F# language could reveal traits as units composed using parameter instantiation.
Mantras:
- Parameters should be parameters
- Composition should by default result in things that are simpler than the components being composed.
To follow up, a C# example like this becomes something like this in F# thinking (I've taken some liberties with this - this is using the class inheritance features available in F# - but since the example is single inheritance this is enough to indicate the points made above
type Semigroup<'A>(append: 'A -> 'A -> 'A) = // note 'append' is a function parameter
member __.Append(x, y) = append x y
type Monoid<'A>(empty, append) =
inherit Semigroup<'A>(append) // this construct is class inheritance in F#, there are no traits yet, nor trait inheritance
member __.Empty = empty
member __.Concat(xs) = Seq.fold append empty xs
type MString() =
inherit Monoid<string>("", (+)) // again this is class inheritance
type MArray<'A>() =
inherit Monoid<'A[]>(Array.empty, Array.append)
type MEnumerable<'A>() =
inherit Monoid<seq<'A>>(Seq.empty, Seq.append)
Note the systematic distinction between parameters (required operations) and published methods (provided operations). In this case, each parameter also happens to be published, but that is most definitely not always the case in practice - this symmetry typically only applies for simple examples.
Note also that the use of parameters means that many lines disappear in F# when connecting exiting functionality (Array.empty, Array.append) into the implementation.
cartermp
Horusiath
tpetricek
wallymathieu
zpodlovics
robkuz
StevenRasmussen
jnm2
HaloFour
MichalStrehovsky
abelbraaksma
Lanayx
realvictorprm
Serentty
I propose we add support for consumption and production of methods on interfaces with concrete implementations to enable the following:
The existing way of approaching this problem in F# is to either:
Additionally, it is important to call out that this requires a runtime change for .NET. The change for the runtime is currently being driven and coordinated by the C# and .NET runtime teams.
Description
The syntax for interfaces would be extended to permit the following:
❗️ The following syntax and concepts are a starting point, and absolutely need discussion. ❗️
Concrete member bodies
To begin, there needs to be a way to specify a concrete body for a member in an interface:
A class that implements this interface need not implement its concrete method:
The same would apply for object expressions:
Note that a class does not inherit members from the interface, so the following code would be illegal:
Member modifiers
The default modifier for interface members is
public. That is, the following member is public:The following access modifiers could be added:
public,internal, andprivate:This is keeping in line with access modifiers being added in C#.
Overriding members
Interfaces could override default members from other interfaces:
Open question: Should explicit naming like this even be a thing?
Overrides are useful to provide more useful "versions" of methods. For example, a new
First()method onIEnumerablemay have a much more efficient implementation on the interfaceIList.Note that no overriding would occur unless specified with the keyword
override.Reabstraction
A default member in an interface could also be overridden to be made abstract again:
If permitted, the
abstractkeyword should be required. This is currently also an open issue for C#. We should only implement this if C# does.Most specific override
I would imagine we do the same as C# here:
For example:
This rule ensures that ambiguities from diamond inheritance are resolved by the programmer.
staticandprivatemembersBecause interfaces could have concrete default implementations, common code could be abstracted into
staticandprivatemembers. There are some open issues for C# here today.This could, in effect, turn interfaces into something in between what we use today and abstract classes. It's a bit iffy to me. I wouldn't want something like
let-bound values in them, either.Base interface invocation
Code in a type that derives from an interface with a default method can explicitly invoke that interface's "base" implementation:
Note that the syntax is
Type.base.Member. This is, in keeping with the theme of this suggestion, in line with the C# spec for the feature.Additionally, the C# team has verified that these changes would not affect existing programs. I would expect anything we do for F# also not affect existing programs.
Pros and Cons
The advantages of making this adjustment to F# are:
The disadvantages of making this adjustment to F# are
Extra information
Estimated cost (XS, S, M, L, XL, XXL): XL
Related information:
Affidavit (please submit!)
Please tick this by placing a cross in the box:
Please tick all that apply: