3 ms·

I haven't used F# in a while, but it seemed pretty clean for OOP with a couple of caveats. You have to explicitly implement interfaces and do a lot of casts to

by mcbits 10y ago

I haven't used F# in a while, but it seemed pretty clean for OOP with a couple of caveats. You have to explicitly implement interfaces and do a lot of casts to use interface members, which is ugly compared to the rest of F#. It's also difficult (impossible?) to have circular references between types unless you cram it all into one file. It's probably possible to convince me that the limitation on circular references is actually a feature, but implicit interfaces would be really nice to have. If I ever dive back into to F#, I think I will treat it as "procedural first with a neat type system" and limit the use of both OO and functional features to where they markedly improve the code.

dualogy 10y ago
> It's probably possible to convince me that the limitation on circular references is actually a feature Have that in Haskell as well. As the community largely views FP as "type-driven development" and Haskell as a "typeful language", it isn't uncommon to have a single module just for listing all the Algebraic Data Types (not their "methods" though, that's more an OOP concept anyway). Having all ADTs at a glance has its own benefits in terms of "high-level overview" etc too of course. But of course the question was about OOP so you're right calling this a "caveat" in that respect.
yawaramin 10y ago
> If I ever dive back into to F#, I think I will treat it as "procedural first with a neat type system" and limit the use of both OO and functional features to where they markedly improve the code. This may be a good strategy; I would urge you though to try doing top-down design in F# using modules and interface (.fsi) files. E.g., let's design a calculator GUI app in F# using, say, Windows Forms. Sketch out the interface first: (* Calculator.fsi *) namespace CalculatorApp module Calculator = type number = Zero | One | Two | ... | Nine type op = Plus | Minus | ... | Sqrt (* Holds the app model. Note that it is mutable; the keypress operations return `unit`, i.e. they update the `t` value in place. *) type t val init : t val press_number : t -> number -> unit val press_op : t -> op -> unit val calculate : t -> double (* Draws the app and hooks up event handlers to the above operations. *) val render : unit -> System.Windows.Forms.Control Then in the implementation file (Calculator.fs), fill in the blanks based on the types! Of course you'll need a separate file for the main entry point, but that's good practice anyway.

by mcbits 10y ago

dualogy 10y ago

> It's probably possible to convince me that the limitation on circular references is actually a feature Have that in Haskell as well. As the community largely views FP as "type-driven development" and Haskell as a "typeful language", it isn't uncommon to have a single module just for listing all the Algebraic Data Types (not their "methods" though, that's more an OOP concept anyway). Having all ADTs at a glance has its own benefits in terms of "high-level overview" etc too of course. But of course the question was about OOP so you're right calling this a "caveat" in that respect.

yawaramin 10y ago

> If I ever dive back into to F#, I think I will treat it as "procedural first with a neat type system" and limit the use of both OO and functional features to where they markedly improve the code. This may be a good strategy; I would urge you though to try doing top-down design in F# using modules and interface (.fsi) files. E.g., let's design a calculator GUI app in F# using, say, Windows Forms. Sketch out the interface first: (* Calculator.fsi *) namespace CalculatorApp module Calculator = type number = Zero | One | Two | ... | Nine type op = Plus | Minus | ... | Sqrt (* Holds the app model. Note that it is mutable; the keypress operations return `unit`, i.e. they update the `t` value in place. *) type t val init : t val press_number : t -> number -> unit val press_op : t -> op -> unit val calculate : t -> double (* Draws the app and hooks up event handlers to the above operations. *) val render : unit -> System.Windows.Forms.Control Then in the implementation file (Calculator.fs), fill in the blanks based on the types! Of course you'll need a separate file for the main entry point, but that's good practice anyway.