m i n d c o d e

How many times have you written an ‘if’ statement like this:

if ((a && b) || !a) ...

You can think of condition ‘a’ behaving like a switch. Its like saying, if the switch is on, please take into account condition ‘b’ in order to do something; if it is off, then simply do it*. Now rewrite ‘a’ and ‘b’ as larger, real-word, classes’ fields/properties, mix more logic evaluation, and voila: an unreadable long expression.

Funny thing is, there *exists* a boolean operator that evaluates the very same way: it is called “implication”. Unfortunately, C# doesn’t have a keyword for it (same with Java, Python…). If it had, the code could be written as simple as:

if (a -> b) ...

Far more readable to me. Maybe they didn’t wanted to use the -> symbol because of the C++ syntax heritage? Who knows…

* Real-world example? Easy. You want to override the display of a dialog-box: if the switch is on, the application always asks for user confirmation; if it is off, it simply executes whatever it needs to.

Update: Hugo Ferreira (same name as mine), as pointed out that you can simplify ((a && b)  || !a) to (!a || b); thank you.

Consider the following code:

public class TestEvent {
  public event EventHandler FireUp;
  public void InvokeFireUp() {
    if (FireUp != null) FireUp(this, EventArgs.Empty);
  }
}

class Program {
  static void Main(string[] args) {
    List<TestEvent> fires = new List<TestEvent>();
    for (int i = 0; i < 10; i++) {
      TestEvent t = new TestEvent();
      t.FireUp += delegate { Console.WriteLine(i); };
      fires.Add(t);
    }

    foreach (TestEvent t in fires) t.InvokeFireUp();
    Console.ReadLine();
  }
}

If you are expecting it to print the numbers from 1 to 10 then you’re wrong The thing is, external variables used in anonymous delegates are passed by reference (even value types like int). In the loop, the variable i is not recreated but increased by one. In the end, i will contain the last value and every event fired will simply write down the value 10. To work as intended, you should write the loop as follows:

for (int i = 0; i < 10; i++) {
  int j = i;
  TestEvent t = new TestEvent();
  t.FireUp += delegate { Console.WriteLine(j); };
  fires.Add(t);
}

Because j is defined “inside” the loop, it will always be a new variable (and hence a new reference in memory).

In my previous post I argued about the behavior of the protected keyword in C# being counter-intuitive. Some people commented on my post (to whom I thank for the participation), with several kind of reactions: there were suggestions to just change the field to public, to make a getter/setter method (property in C#), to go back to university and stay awake in OOP classes (*sigh*), and to use a real language instead of a Microsoft one (eheh). I’ll try to answer to all of those comments here, because I believe that understanding the languages we work with is important to develop correct and sophisticated programs using the Object Oriented paradigm (and not just write C with Classes).

To clarify further the issue, let’s just call stuff by their name: the concept we are discussion is called Access Modifiers. Access Modifiers are also used in C++, Java, Smalltalk and several other OO (arguably more or less) languages. Access Modifiers exist to aid the process of Information Hiding which is part of the Encapsulation strategy used in OO (or separation of concerns). Some argue that Encapsulation and Data Hiding are the same. Personally (and several other people including some from the Python and Java community) I tend to disagree. But the important concepts to stick around can be summed up by the following quote from wikipedia:

“In computer science, the principle of information hiding is the hiding of design decisions in a computer program that are most likely to change, thus protecting other parts of the program from change if the design decision is changed. The protection involves providing a stable interface which shields the remainder of the program from the implementation (the details that are most likely to change). In modern programming languages, the principle of information hiding manifests itself in a number of ways, including encapsulation (given the separation of concerns) and polymorphism.”

You may follow the links for further information, but the main reasoning I’m trying to follow here is that using public everywhere around is bad (I’ve seen this countless times). It can appear to be harmless in simple/academic applications, but when designing a full blown framework that will be used by other people, don’t ever underestimate the capacity of users to screw up things (including yourself after you decide to reuse a component you’ve done 1 month ago and don’t remember that, while that field is public, YOU SHOULDN’T TOUCH IT!!).

That said, lets look at the definition given by Microsoft to their Access Modifiers:

• public: The type or member can be accessed by any other code in the same assembly or another assembly that references it.
• private: The type or member can only be accessed by code in the same class or struct.
• protected: The type or member can only be accessed by code in the same class or struct, or in a derived class.
• internal: The type or member can be accessed by any code in the same assembly, but not from another assembly.

Still with me? Great. Everyone knows public well enough. Internal is simple to understand too. But if you think private and protected follow the same rational, guess what: you’re wrong. Compare the following code with the one in the last post:

class A {
  private int protectedField;
  public void doStuff(A a) {
    a.protectedField = 3;
  }
}

class Program {
  static void Main(string[] args) {
    A a = new A();
    A aa = new A();
    aa.doStuff(a);
  }
}

It compiles, as it should! Though members doStuff and protectedField are of different instances, they are defined in the same class. Look at the definition of private: “The type or member can only be accessed by code in the same class or struct”. Are you following me? Private basically says: “I don’t care who tries to access this member, as long as it is within the context of the same *class*.”

Now let’s remember the code using protected:

class A {
  protected int protectedField;
}

class B: A {
  public void doStuff(A a) {
    a.protectedField = 3;
  }
}

It fails to compile, though the definition of protected says: “The type or member can only be accessed by code in the same class or struct, or in a derived class.” Can you spot the differences? The text is the same except that it adds “or in a derived class”. Well, B derives from A. So what is the problem? The problem, it seems, has nothing to do with instances being different. The exact error code the compile gives is: “Cannot access protected member ‘A.protectedField’ via a qualifier of type ‘A’; the qualifier must be of type ‘B’ (or derived from it)”. So in order for the member doStuff to have access to the protected field, a should be typed as B, despite the fact that protectedField is defined in A.

I would personally like to know the person who thinks this is intuitive (and sorry, but I will not even discuss why not just simply cast A to B).

To finalize, I just want to point out that these posts are called C# for a reason: this behavior does not emerge in Java For example, the following code compiles and runs perfectly in JRE6:

public class A {
  protected int protectedField;
}

public class B extends A {
  public void doStuff(A a) {
    a.protectedField = 3;
  }
}

What is wrong with this code?

public class A {
  protected int campoProtegido;
}

public class C: A {
  public void doStuff(A a) {
    a.campoProtegido = 3;
  }
}

Actually, it won’t compile. It seems that the protected keyword only works at the instance context. So, although class C is a subtype of A, because it is a different instance than the instance of A we are trying to access, it fails at compile time in line 7. So much for encapsulation…

Any ideas besides turning the field campoProtegido public?