FSharp3Sample Discussions Rss Feed

New Post: Unable to load the solution on VS2010 and VS2012 Express

VallarasuS — Wed, 19 Sep 2012 09:49:29 GMT

VS2010 complains the solution is created by a newer version, VS12 complains this project is unsupported.

How can I resolve this?

Thanks,

Val

New Post: Use of pattern matching to implement standard design patterns affects extensibility

ttliu2000 — Mon, 30 Apr 2012 04:05:16 GMT

Great suggestion, Gdecaso..

we will make a change according to your suggestion.

New Post: License

ttliu2000 — Mon, 30 Apr 2012 03:36:26 GMT

Thank you!

the license is:

Apache License
Version 2.0, January 2004
http://www.apache.org/licenses/

New Post: OO Design patterns are not "advanced F#"

Thorium — Wed, 25 Apr 2012 21:47:39 GMT

In my opinion advanced F# would be language specific features like:

- Builder pattern (computational expressions)

- MailboxProcessor

- Numeric literals

- Active pattern (not very useful, but is already...nice!)

- Quotations

- ...

New Post: Use of pattern matching to implement standard design patterns affects extensibility

Thorium — Tue, 27 Mar 2012 04:01:04 GMT

Design Patterns are common "best practice" ways to manage object-oriented problems that doesn't exist in functional language. While it is nice to have some sample code here, I think OO-patterns may noy be the best thing.

Why would you use ICommand anyway? Next you need some IHasPermission to check that no-one can't inject your code. And so on. While you could use the function as type in the first place.

Or if you absolutely want to just execute:

let Do f = f()

(silly method) or maybe:

let Do hasPermissions f = 
    if hasPermissions() then f()

Generally I would say extensibility is not the problem in functional programming as it is in OO-world. The reason is that with OO you try to bottom-up model the whole world. In functional programming you can use partial application and compose things with top-down design.

I could make:

let myProcess = Save >> Validate >> Send

without even yet defining the parameter, the object x, when in OO I should first define every property of this x.

Usually business logic is messy unstructured if-jungle.
You can solve this with pattern matching which keeps your complex logic clean.

I discussed this with a Java-architect and here are some examples of his sample Java-code as F#:
http://pastebin.com/2uKMDRsx
http://pastebin.com/BQfCu0fS

New Post: OO Design patterns are not "advanced F#"

Thorium — Tue, 27 Mar 2012 02:58:45 GMT

GoF Design patterns described by this sample pack are not advanced F# but object oriented programming.

They should be under some other topic than "Advanced".

How about "Avoid"?

New Post: Beta needs web services updates

danfay — Tue, 20 Mar 2012 18:28:58 GMT

Installed the 3.0 Samples Beta - there are a few build errors - mainly having to do with the web services.

New Post: License

ziaw — Tue, 29 Nov 2011 06:01:31 GMT

Hello

How can I use this samples as example for produce another language sample pack?

It is Nemerle language, semantically it closest to F#. Of course, links to http://fsharp3sample.codeplex.com will be published.

Thanks for the great work!

New Post: Use of pattern matching to implement standard design patterns affects extensibility

gdecaso — Tue, 18 Oct 2011 12:34:56 GMT

Hi,

I'm an avid F# 2.0 user as well as some prior experiences with Java, where I used design patterns quite aggressively.

While looking at the design patterns proposed in this project, I see that most of them (if not all of them) are implemented using pattern matching. While this might seem natural and easy to read in a language like F#, it is generally not recommended when designing software in general, since pattern matching violates the open/closed principle (see http://en.wikipedia.org/wiki/Open/closed_principle).

For instance, the command pattern example posted in this project (http://fsharp3sample.codeplex.com/wikipage?title=Command%20pattern) defines a CommandType as an enumerate with two values Deposit and Withdraw. The Do and Undo functions pattern match on these enumerate values to decide what to do.

While this achieves the desired functionality, it provides no extensibility at all. If I wanted to add a third operation (say PrintBalance), I would have to manually change all of the places where the CommandType is pattern matched (I have to admit that the F# compiler would warn if one such pattern matching expression is not updated, but still..).

In my opinion, this design pattern would be better implemented if the TCommand type is defined as follows:

type TCommand =
   { Amount : int
      Do: int -> int -> int;
      Undo: int -> int -> int;
      Name: string }

let withdraw x = { Amount = x; Do = (-); Undo = (+); Name = "Withdraw" }

let deposit x = { Amount = x; Do = (+); Undo = (-); Name = "deposit" }

let operate (balance: int) (c: TCommand) =
  printfn "Doing a %s operation" c.Name
  let newBalance = c.Do c.Amount balance
  printfn "New balance is %O" newBalance 
  newBalance

Excuse me if it does not compile, I have no access to an F# compiler right now (not even http://www.tryfsharp.org, due to browser plug-in requirements).

Thanks,

Guido

New Post: Use of pattern matching to implement standard design patterns affects extensibility

gdecaso — Tue, 18 Oct 2011 12:34:56 GMT

Hi,

I'm an avid F# 2.0 user as well as some prior experiences with Java, where I used design patterns quite aggressively.

In my opinion, this design pattern would be better implemented if the TCommand type is defined as follows:

type TCommand =
   { Amount : int
      Do: int -> int -> int;
      Undo: int -> int -> int;
      Name: string }

let withdraw x = { Amount = x; Do = (-); Undo = (+); Name = "Withdraw" }

let deposit x = { Amount = x; Do = (+); Undo = (-); Name = "deposit" }

let operate (balance: int) (c: TCommand) =
  printfn "Doing a %s operation" c.Name
  let newBalance = c.Do c.Amount balance
  printfn "New balance is %O" newBalance 
  newBalance

Excuse me if it does not compile, I have no access to an F# compiler right now (not even http://www.tryfsharp.org, due to browser plug-in requirements).

Thanks,

Guido