3

So to add onto what I learned from this question I asked:

F# Records: Dangerous, only for limited use, or well used functionality?

This got me thinking about whether I should be using Types with methods or Records(?) AND methods. For example, this is a typical type I might make:

(* User Interaction Start *)

type UserInteraction public() = 

  member public x.CreatePassword(originalPassword) =
    if String.IsNullOrEmpty originalPassword then
      raise(new ArgumentException "CreatePassword: password is null or empty")
    let hashUtility = new HashUtility();

    hashUtility.CreateHash originalPassword

The problem I could see with this is there's a possibility that something within that UserInteraction type is mutable due that being allowed. Now with record types, as far as I understand, they are guaranteed to be immutable.

Would it be better design a module with methods that take in or return record types only or even go one step further with method chaining?

Community
  • 1
  • 1
Programmin Tool
  • 6,507
  • 11
  • 50
  • 68
  • 1
    Bettering myself in the functional world really. I'm pretty new to functional programming so I'm trying to figure out if I am, despite trying against it, just forcing imperative rules because F# allows it. – Programmin Tool Jan 11 '12 at 20:43
  • 1
    How is this a Scala question? Scala doesn't have something precisely analogous to F# records, and you can easily control whether something is mutable or immutable by declaring it `val` or `var`. (Plus you can always hide mutable state somewhere if you work at it hard enough.) – Rex Kerr Jan 11 '12 at 20:47
  • @ProgramminTool: It sounds like a broad goal to me. If you can add more contexts to your code snippet, people may come up with concrete advices. – pad Jan 11 '12 at 20:52
  • I really recommend reading the Real World Functional programming samples by Tomas Petrick: http://msdn.microsoft.com/en-us/library/hh314518.aspx – David Grenier Jan 11 '12 at 21:52

2 Answers2

8

You may want to read When to Use Classes, Unions, Records, and Structures [MSDN] (bottom of the page). You appear to have some incorrect assumptions about records. For instance, they can have mutable fields just like classes. The important differences are inheritance, pattern matching, constructors, hidden members, equality, and copy-and-update expressions.

Just noticed one small error on that page: records can, in fact, implement interfaces.

Another possibly helpful section: Differences Between Records and Classes [MSDN] (bottom of page)

Daniel
  • 47,404
  • 11
  • 101
  • 179
3

Note that you can create a member on an immutable type returning a new modified instance of the type which is a perfectly reasonable thing to do:

type Person =
    { Name : string; Age : int }

    member x.GrowOlder n =
        { x with Age = x.Age + n }

let q = { Name = "David"; Age = 29 };;
q.GrowOlder 1

It is interesting to note that in the following C# code:

var x = 0;
var y = 1;
var z = x + y;

You wouldn't expect neither x nor y to be mutated by the use of the operator +, that is + returns a new value and does not mutate x nor y. You can generally consider designing everything with that in mind.

ildjarn
  • 62,044
  • 9
  • 127
  • 211
David Grenier
  • 1,098
  • 6
  • 17