The usual technique is to use an option, and to expose a property, e.g.

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

type interfaceA = interface 
    abstract getAddress : unit -> string
    abstract setAddress : string -> unit
end

type TestClass() = class
    let mutable fieldA: interfaceA option = None
    member x.Address 
        with get() = 
            match fieldA with 
              | None -> failwith "Address not set" 
              | Some a -> a
        and set(v) = 
            fieldA <- Some(v)
end

F# isn't thrilled about null values for types defined within F#, since they are a common cause of program failure. There are ways to get null values for any reference type, if you really want to (for various .NET reasons we can't actually stop that), but the language default is to prevent to make the use of nulls significantly less common through a range of type checking rules.

There's also been a request to allow an attribute annotationon a type to say "let me use null with this type".

Kind regards

don

By on 5/27/2007 3:59 AM ()

Thanks a lot.
About second question.
There is class implemented interfaceA

type ConcretInterfaceA = class
val mutable address: string
interface interfaceA with
member x.getAddress() = x.address
member x.setAddress(v) = x.address <- v
end
new(v) = {address = v}

end

let test = new TestClass()
let Concret1 = new ConcretInterfaceA ("test");

test.Address <- (Concret1 :> interfaceA)
Is it really necessary always do :> operation?

PS May be is there any articles like "ocaml or F# object orientation programming for C# programmer"?

By on 5/27/2007 8:51 AM ()

Hi,

Yes and no. Upcats are indeed sometimes needed in F# when you are explicitly throwing away information like this. However, once you get the hang of OO programming in F# you will find you don't need to use this pattern (a class specifically to implement an interface) as much as you may think. Instead it becomes much more common to use object expressions and closure to implement interfaces. This is done throughout the "Seq" implementation in ienumerable.fs in the standard library. So you'll find yourself writing this sort of thing instead:

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

#light

type InterfaceA = interface 
    abstract getAddress : unit -> string
    abstract setAddress : string -> unit
end

let ConcreteInterfaceA(v) = 
    let address = ref v
    { new InterfaceA with 
        member x.getAddress() = !address
        member x.setAddress(v) = address := v }

let test = new TestClass()
let Concrete1 = ConcreteInterfaceA ("test");
test.Address <- Concrete1 

Re your second question: yes, again it is necessary to explicitly cast to access an interface. This is needed because different interfaces supported by a object may have methods with identical names and signatures but different implementations.

BTW I guess I would use property notation for your example:

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

type InterfaceA = interface 
    abstract Address : string with get,set
end

let ConcreteInterfaceA(v) = 
    let address = ref v
    { new InterfaceA with 
        member x.Address 
            with get() = !address 
            and set(v) = address := v }

Regards

Don

By on 5/27/2007 12:11 PM ()

Thanks. My brain is damaged. =)
It is so not intuitively in contrast with C#.

By on 5/28/2007 9:46 AM ()

Hi ais,

F# is not foremost an OO language, so you should probably first try to master functional programming first, then come back to OO. If you have some real code (rather than translations of snippets) then that might also help, as people here can then help describe how to approach writing code from an F# perspective.

You might like to take a read of Foundations of F#, by Robert Pickering, which covers these topics, or the drafts of Chapters 3, 4 amd 6 of Expert F#.

Kind regards,

Don

By on 5/28/2007 10:54 AM ()

Hi. I want start programming in F# because I hate { and }. =) I don't know how programming more or less complex program without OO. And first of all I need to undestand the OO side of language. Today I tried to coding an abstract factory, and my brain is demaged again =).
Start reading Expert F#, thanks.

By on 5/28/2007 1:01 PM ()
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