Back to Questions
1.1k
views3
comments
getting rid of circular references
f#

I am creating a singleton object. This object has several static methods dealing with the one and the only object instance. For this to work I also need a 'static let binding' (is this a proper term?), what creates a circular reference between the let binding and the type definition which forced me to set object as the type for the let binding. In a related posting Kurt suggested a workaround:

... Right onthe circular reference - the workaround I've used below is to split the type into two parts. Not stellar, but at least it has no runtime overhead. I believe mutually recursive type and let bindings will be addressed in future F# releases.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

type Manager (filters: Map<string, string>) =
  member this.Filters = filters
  static member private lock = new obj()

let active: Manager option ref = ref None
   
type Manager with
  /// Retrieves the current active template manager
  static member GetActiveManager = 
  lock (lock) ( 
  fun () -> 
  match !active with 
  | Some v -> v 
  | None -> 
  let m = new Manager(Map<string, string>([]))
  active := Some m
  m
  )

Unfortunately my situation has an additional complication. The manager method has to implement an interface and one of the methods of the interface should also use the let binding. My understanding is that the interface definition has to be specified the first time type is introduced. Which leaves me back in square one. I was thinking about what else can be done, i.e. I can declare this method as an abstract one, and then inherit the class with the real implementation from the abstract one, but all of this becomes really messy really fast.

A related problem is the initialization of the ref binding: If the constructor of the Manager would be available within the let, I can create the initial version of the manager within the let, which would make unnecessary all this logic and validation inside of the GetActiveManager

Any ideas?

.

I probably should've suggested this instead, instead of that needlessly complex thing:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

type Manager (filters: Map<string, string>) =
  member this.Filters = filters
  static member private lock = new obj()
  static member private active: Manager option ref = ref None
  static member GetActiveManager = 
      lock (lock) ( 
        fun () -> 
          match !Manager.active with 
          | Some v -> v 
          | None -> 
          let m = new Manager(Map<string, string>([]))
          Manager.active := Some m
          m
      )

I've made active private, I assumed the GetActiveManager method should encapsulate it. An advantage of this approach.Also consider the code given in the original thread to abstract out the singleton related code.Edit: If you prefer lets:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

type Manager (filters: Map<string, string>) =
  static let active: Manager option ref = ref None
  static let lockMgr = new obj()
  member this.Filters = filters
  static member GetActiveManager = 
      lock (lockMgr) ( 
        fun () -> 
          match !active with 
          | Some v -> v 
          | None -> 
          let m = new Manager(Map<string, string>([]))
          active := Some m
          m
      )
By on 3/29/2009 12:37 PM ()

You are absolutely right, encapsulating it all inside the manager class was the intention from the start. With your help I ended with the following:

1
2
3
4
5
6
7

type Manager (filters: Map<string, string>) =
  static let active = ref new Manager(Map<string, string>([]))
  static let lockMgr = new obj()
  member this.Filters = filters
  static member GetActiveManager = 
  lock (lockMgr) (fun () -> !active)
.....

BTW, the difference between the lets and members seems to be more than a matter preference: when I tried to run it with members, it was executing the obj() every time the lockMgr was requested, effectively defeating the locks

By on 3/29/2009 3:04 PM ()

BTW, the difference between the lets and members seems to be more than a matter preference: when I tried to run it with members, it was executing the obj() every time the lockMgr was requested, effectively defeating the locks

Right. Can't believe I fell for that one _again_ :) The reason is that static members are actually properties, while static lets are fields...In C# you would have:

1

static object LockMgr{  get  {    return new object();  }}

which makes it more obvious what's going on.

By on 3/30/2009 12:36 AM ()

    Topic tags

    IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
    Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy     		Built with WebSharper