F# Objects – Integration with the other .Net Languages – Part 2
Posted
by MarkPearl
on Geeks with Blogs
See other posts from Geeks with Blogs
or by MarkPearl
Published on Thu, 29 Apr 2010 15:36:01 GMT
Indexed on
2010/04/29
16:58 UTC
Read the original article
Hit count: 221
So in part one of my posting I covered the real basics of object creation. Today I will hopefully dig a little deeper…
My expert F# book brings up an interesting point – properties in F# are just syntactic sugar for method calls. This makes sense… for instance assume I had the following object with the property exposed called Firstname.
type Person(Firstname : string, Lastname : string) = member v.Firstname = Firstname
I could extend the Firstname property with the following code and everything would be hunky dory…
type Person(Firstname : string, Lastname : string) = member v.Firstname = Console.WriteLine("Side Effect") Firstname
All that this would do is each time I use the property Firstname, I would see the side effect printed to the screen saying “Side Effect”.
Member methods have a very similar look & feel to properties, in fact the only difference really is that you declare that parameters are being passed in.
type Person(Firstname : string, Lastname : string) = member v.FullName(middleName) = Firstname + " " + middleName + " " + Lastname
In the code above, FullName requires the parameter middleName, and if viewed from another project in C# would show as a method and not a property.
Precomputation Optimizations
Okay, so something that is obvious once you think of it but that poses an interesting side effect of mutable value holders is pre-computation of results.
All it is, is a slight difference in code but can result in quite a huge saving in performance. Basically pre-computation means you would not need to compute a value every time a method is called – but could perform the computation at the creation of the object (I hope I have got it right). In a way I battle to differentiate this from lazy evaluation but I will show an example to explain the principle.
Let me try and show an example to illustrate the principle… assume the following F# module
namespace myNamespace open System module myMod = let Add val1 val2 = Console.WriteLine("Compute") val1 + val2 type MathPrecompute(val1 : int, val2 : int) = let precomputedsum = Add val1 val2 member v.Sum = precomputedsum type MathNormalCompute(val1 : int, val2 : int) = member v.Sum = Add val1 val2
Now assume you have a C# console app that makes use of the objects with code similar to the following…
using System; using myNamespace; namespace CSharpTest { class Program { static void Main(string[] args) { Console.WriteLine("Constructing Objects"); var myObj1 = new myMod.MathNormalCompute(10, 11); var myObj2 = new myMod.MathPrecompute(10, 11); Console.WriteLine(""); Console.WriteLine("Normal Compute Sum..."); Console.WriteLine(myObj1.Sum); Console.WriteLine(myObj1.Sum); Console.WriteLine(myObj1.Sum); Console.WriteLine(""); Console.WriteLine("Pre Compute Sum..."); Console.WriteLine(myObj2.Sum); Console.WriteLine(myObj2.Sum); Console.WriteLine(myObj2.Sum); Console.ReadKey(); } } }
The output when running the console application would be as follows….
You will notice with the normal compute object that the system would call the Add function every time the method was called. With the Precompute object it only called the compute method when the object was created. Subtle, but something that could lead to major performance benefits.
So… this post has gone off in a slight tangent but still related to F# objects.
© Geeks with Blogs or respective owner