A Developer's Experience

You may not know the guy in black; but you sure should be knowing the guy in green. Don't know him ? I am not a patron of his philosophies against planned design. But he sure is a great guy with lots of good ideas. It was nice having an hour long chat with him.

Alright, it is a long wait. And I am going to keep it short. Recap of the problem: Why did the ref variable in SomeMethod not get the expected result ( DayOfWeek.Friday ) when called from a different thread? Boxing. Yes, that is the culprit. Sometimes, it is subtle to note. DayOfWeek is an enum - a value type. When the method is called from a different thread, we put the argument (arg3) in an object array, and that's where the value gets boxed. So we happen to assign the resultant value to the boxed value. So how do resolve the issue? Simple.......assign the value back from the object array to the ref variable. int SomeMethod(string arg1, string arg2, ref DayOfWeek arg3) { if (Dispatcher.CheckAccess()) { var funcDelegate = (Func<string, string, DayOfWeek, int>)SomeMethod; var args = new object[] { arg1, arg2, arg3 }; int retVal = Dispatcher.Invoke(funcDelegate, args); arg3 = ...

Straight to code..... int SomeMethod(string arg1, string arg2, ref DayOfWeek arg3) { // Wildest implementation! } The above method had to be executed on its dispatcher thread. So let unravel a bit of the wildest implementation above. int SomeMethod(string arg1, string arg2, ref DayOfWeek arg3) { if (Disptacher.CheckAccess()) { var funcDelegate = (Func<string, string, DayOfWeek, int>)SomeMthod; return Dispatcher.Invoke(funcDelegate, arg1, arg2, ref arg3); } // Wilder implementation!! } Before you say anything, yes, the compiler spat the following errors:- Error 1 No overload for 'SomeMethod' matches delegate 'System.Func<string,string,DayOfWeek,int> Error 2 The best overloaded method match for 'System.Windows.Threading.Dispatcher.Invoke(System.Delegate, params object[])' has some invalid arguments Error 3 Argument '4': cannot convert from 'ref System....

Currying is a mathematical concept based on lambda calculus. It is a technique of operating on a function (taking multiple arguments) by splitting and capable of chaining into a series of single argument functions. It is very similar to what a human would attempt to do on paper. For example, if you have to add numbers 1 through 10, what would you do? Class II mathematics....zero in hand, one in the mind, add 0 and 1, so 1 in the mind, then 2 in the hand, ...up to 10. So we compute the addition with one argument at a time. In the programming world, it is realized by transforming a n-arguments function into a (n-1) arguments function, which takes the remaining one argument. This transformation when applied recursively on each of the single argument functions is the chaining of single argument functions that I discussed earlier. Needless to say, currying is a gift of the functional programming world. In simple words, functional programming is about building functions from other functio...

template<typename A, typename B> class TClass { public: TClass() { } // Overload #1 public: std::string SomeMethod(A a, B b) { std::ostringstream ostr; ostr << a << "-" << b; return ostr.str(); } // Overload #2 public: std::string SomeMethod(B b, A a) { std::ostringstream ostr; ostr << b << "-" << a; return ostr.str(); } }; So that is a template class with SomeMethod overloads. Why would somebody write such a class? Imagine it is an adder class, and the method overloads could used to add with parameters specified in either order. Following is the way one could use the above (based on the adder example):- int i = 45; double d = 12.3f; TClass<int, float> t1; const std::string idText = t1.SomeMethod(i, d); // This calls Overload #1 const std::string diText = t2.SomeMethod(d, i); // T...

We all know C# does not offer multiple inheritance but offers arguments that programmers can live without it. It is true in almost all cases, especially all cat and animal or employee and manager projects. I have seen a few cases where if C# offered multiple inheritance, the solution would have been natural, elegant and succinct. Imagine that I have a component (UI, non-UI, doesn't matter). You can make calls into the component, which does some interesting work for you. Imagine that the component takes an interface IComponentCallback to notify its parent. So I would do is have my parent class derive from IComponentCallback interface and pass this to the component. The code would look something like this:- interface IComponentCallback { void Callback1(); bool Callback2(); void Callback3(int old, int new); } class SomeComponent { // The parent on whom callbacks are made private IComponentCallback _parent = null; public SomeCompoent(IComponentCallback cmpCal...