Fun with C#: Before there were dynamic features

In my previous post, I mentioned about Visual FoxPro being a weakly-typed, dynamic, object-oriented language, which also featured it’s own SQL (Structured Query Language), and a fast local database. When I got to C#, I found a language that was strongly-typed, object-oriented, with no easy way to perform queries, and very hard to create dynamic behavior. But let me brake that down, pretty much the way I did with FoxPro in the previous post:

Object-Oriented

Instantiate an object and call a method on it. Similar to the way I did in FoxPro, but with a key difference: the class name isn’t a string passed into a function!

User user = new User();
user.SayHello();

SQL (Structured Query Language)?

In the first two versions of C# there was just no easy way to query things. But then we were presented with LINQ (Language Integrated Query) in version 3!!

myCustomers = from c in customers 
                           where c.Id == 1 
                           select c;

customer = myCustomers.SingleOrDefault();

customer.Address 
customer.PhoneNumber 

That was very similar to the way I could do a SELECT followed by a SCATTER in FoxPro. I loved it!

I didn’t like the way the code read, though, with the “select” coming at the end (after so many years of starting my queries with SELECT). Once I got over that, I started to appreciate the fact that I could write my queries like this:

customer = customers.where(c => c.Id == 1).SingleOrDefault();

Or even better, like this:

Customer customer = customers.SingleOrDefault(c => c.Id == 1);

“What does that have to do with the topic of this series?”, you might ask. Stay with me…

Strongly-typed

Consider the following code:

var myVariable = 1234;
myVariable = “Woohoo!!”;   // Nope...

Well, since C# is strongly-typed, knowing the type of data we get back from queries is very important. Take this example:

var customers = customers 
                 .SingleOrDefault(c => c.Id == 1)
                 .Select(c => new { Address = c.Address, PhoneNumber = c.PhoneNumber  });

When C# 3 introduced type inference, many developers were confused with the keyword var, thinking it meant “variant”; in other words, a variable declared as var should be assigned different types of data at will. That was not the case; var was just a way to tell the compiler “hey, the type of this variable will be whatever type I’m assigning to it as I declare it.”

With that said, in prior examples we were having the query return a Customer object. In the example above, on the other hand, we return some sort of list of anonynous objects, by using the new keyword without the name of a class, but giving it the properties and initial values we want on them. So we just told the compiler “I need a new object that has these properties with these values”. The compiler creates a class for us containing those properties; it is not a class created dynamically during runtime.

Now, let’s take that example a step further:

var customers = customers 
                  .SingleOrDefault(c => c.Id == 1)
                  .Select(c => new { c.Address, c.PhoneNumber  });

customers = “can’t do this!”;

Again, we declare a customers variable, and let the compiler infer its type. Next, we try to assign some string content to that same variable. The compiler yells at us, proving that var does not mean variant.

Dynamic (before C# Dynamic)

Let’s now have a look at how we implement dynamic things before the so-called “C# Dynamics” were introduced. Let’s revisit this simple sample:

User user = new User();
string hello = user.SayHello();
Console.WriteLine(hello);

What if we didn’t know during compile time what type of User to instantiate? And what if we only knew during runtime what method to execute? The way to that back then was only by using .NET Reflection, like so:

var instanceType = Type.GetType("Playground.User");            
object instance = Activator.CreateInstance(instanceType);            

MethodInfo theMethod = instanceType.GetMethods().SingleOrDefault(m => m.Name == "SayHello");           
object hello = theMethod.Invoke(instance, null); 
           
Console.WriteLine(hello.ToString());

That way, both the class and method names where represent by strings. When doing that, we always work with object; that’s what the Activator’s CreateInstance method returns, and it’s also what the Invoke method on a MethodInfo instance returns. Using type inference here (declaring the variables with var) wouldn’t help us much.

Another option to create some sort of dynamic code back then was by emitting IL (Intermediate Language). Not exactly a fun thing to do. There are good cases for it, though, so check out some real world users of Reflection.Emit.

Yet another option, which I’ve used at least twice in successful projects, was to build C# code as strings within the application, and handle it over to the C# compiler during runtime. What type of code got created dynamically was controlled within the application, and it was executed within a sandbox, so the end-users couldn’t really “do anything they wanted”. In fact, I have used this approach in conjunction with the dynamic features once they become available.

Coming up next, dynamic code after the C# dynamic features arrived. Stay tuned!

Leave a comment

Fun with C#: Dynamic Features – Why did I care?

I was glad to see dynamic features available in C# back when version 4 came out (in 2010, if memory serves me right…). But, why did I care?

Back in my old days, prior to start working with .NET, I was working heavily on Visual FoxPro projects. FoxPro was a weakly-typed, dynamic, object-oriented language, which also featured it’s own SQL (Structured Query Language), and a fast local database. Now, what does all mean?

Object-Oriented

I could define a class (say, “User”), instantiate it, and call methods on it (such as, “SayHello”):

SQL (Structured Query Language)

FoxPro allowed me write code like this:

SELECT Address, PhoneNumber FROM C:\DB\CUSTOMERS.DBF 
    WHRE Id = 1 
    INTO C:\TEMP\TEMP_CUSTOMERS.DBF 

No need to create a connection to a database: I could simply query some data off of a local file, and even dump into to another local file.

I could also create an object out of the current row off my query results, with properties matching the columns in the table (think Entity Framework reading data off a database and pushing into objects for you):

SCATTER NAME customer 
customer.Address 
customer.PhoneNumber 

 

Weakly-typed

We could assign an integer to a variable in one line, and then assign a string to it in another, and FoxPro was happy:

myVariable = 1234 
myVariable = “Woohoo!!”

Nope, that wasn’t necessarily a good thing, as people definitely abused that possibility. However, there were scenarios where it came in handy.

Dynamic

I could do the following:

1. Put the name of a class to instantiate and the name of a method to call in a string (both could be coming from a database):

className = “User”
methodName = “SayHello"

2. Merge those variables to another string variable representing lines of code:

text to someVariable texmerge noshow 
        instance = CreateObject(“<< className >>”)
        result = loInstance.<< methodName >>()
        MessageBox(result)
endtext 

3. Execute the code contained in that string variable like so:

&someVariable 

 

Putting it all together

So it was common to see code somewhat like this:

SELECT ClassName, MethodName 
    FROM WhateverTable 
    WHERE Module == “Hello World”

SCATTER NAME behavior 

text to someVariable texmerge noshow 
        instance = CreateObject(“<< behavior.className >>”)
        result = loInstance.<< behavior.methodName >>()
        MessageBox(result)
    
        result = 1234 
        MessageBox(result)
endtext 

&someVariable 

In reality, some FoxPro projects store entire modules created based off dynamic code like the one above, stored in databases.

Rewriting FoxPro “dynamic” software in .NET

I’ve worked in projects where the client wanted those FoxPro “dynamic” applications rewritten in .NET. I’ve been told many times that “our application is 100% dynamic; everything can be configured by the end-user”. I’ve even blogged about that. In the end, not everything was dynamic, but there were dynamic parts, indeed:

Users could:

  • Extend the system by adding new tables (but always based off existing ones);
  • Add columns to existing tables
  • Define what columns show on the grid
  • Define how columns, rows, and cells where displayed (background color, enable/disable, header, etc.)
  • Create CRUD screens for those columns they added;
  • Create reports using those new columns;
  • Create “expressions” that are evaluated in several situations (enabling/disabling a field, setting the default value of a field based off other fields, etc.). For example, maybe the default value for a new “Total” column in a table should be the result of the following expression (imagine that both Price and Quantity are also columns added by the user):
    • context.Product.Price * context.Item.Quantity
  • Etc.

Reproducing some of those pieces in C# wasn’t exactly easy back then, so this posts answers why I cared about the dynamic features introduced in C# several years ago.

In the next post I’ll go over what I did before the dynamic features of C# came around.

Leave a comment

Fun with C#: Dynamic Features

Most software projects I’ve worked on had at least one feature that needed to be dynamic, where certain aspects of the program wouldn’t be known until runtime. Sometimes, those aspects would be known as the application was running on the developer’s machine (data binding in WPF, for instance, is late bound), and other times, they’d only be known at the end-user’s machine (maybe based on the user’s selections, maybe based on the environment).

Before landing in the strongly-typed world of C#, I used to write software in FoxPro, which was a dynamic language. We used to store large blocks of code on tables in the database, and execute that code during run time after all the required pieces of the puzzle were known. That was not something easy to do in the early days of C#.

There are a number of ways to either add or change behavior of an application during runtime, and granted, doing things in C# exactly the same way we did in FoxPro was NOT the way to go! However, when dynamic features where introduced back in C# 4.0, I was glad to have it in my toolbox, and I believe I’ve found good use for it in several situations.

For this post, my main point is just that I think using the dynamic features in C# is fun. I’ll be writing up more posts to talk about some basic stuff around these features, and also giving some examples on how I’ve used it.

Leave a comment

Misery with C#: Regions…

I feel miserable pretty much everytime I run into regions when going through C# code. Nine out of ten times, regions are the rug where developers sweep ugly code under.

Many, many years ago, I used to use regions like many people still do:

  • to organize my class, grouping fields, properties, methods, etc;
  • to group code according to its functionality (methods and properties related to save go here, those related to validate go there, etc.)

Eventually I finally learned that even that way of using regions was pretty bad. If a class is so big that in order to make it easier to read I need to group and hide things under regions, that means the class is doing too much. Also, if there are multiple groups of funcionality within the same class, that probably means each of those groups represent abstractions that belong somewhere else.

Now, what’s even more aggravating is using regions within method bodies. So you have code, code, code, region, code, code, region, code. I’ve seen methods that had switch-blocks where each case block had code hidden behind regions!!. If some code is within a region inside of a method body, than that code should probably be moved to a separate method!

Now, what do we make out of the example below?

The entire body of that method is hidden behind a region. What should expect to find when we expand that region? Just a few lines of the cleanest code possible, right…? Yeah, right!

If you’re using regions like that, please, take a step back and think how you can get rid of that nasty rug. 🙂

Leave a comment

Fun with C#: Cleaning up dense code with Dictionary and ForEach

I have a personal dislike for code produced by copy-and-paste that forces me to read it over several times so I can spot what’s changed after the block was pasted. Take the code below as an example:

After a while we spot the differences:

There cases where spotting the difference isn’t so easy. Sometimes, it’s a simple “!” somewhere in the code that can be easily overlooked.

Anyway, a couple of posts ago I mentioned how I use dictionary and delegates to get rid of switch-blocks, as well as how I like using ForEach whenever possible. Well, we can clean things up a bit in the code above using the same approach, changing the code to make it look like this:

Much better, I think…

Leave a comment

Fun with C#: ForEach for everyone!

Whenever possible, I like using a ForEach method, instead of a for-each block. Take the code below for example:

The iteration part could be rewritten like so:

Or, even better, since the AddToPizza method takes in one parameter with the same type of the items we’re iterating over…

The iteration could simply look like this:

However, not every thing we iterate has the ForEach method. For example, regular arrays don’t. So, if our items source looked like the one below, we wouldn’t have a ForEach method:

So how do we get a ForEach method that works on Lists, Collections, Arrays, etc? Just create the extension method on IEnumerable<T>, like so:

Make sure to import the namespace for your extension methods (using statement) wherever you’re trying to use them!

Leave a comment

Fun with C#: Object and Collection initializers

I hate looking at dense code. You know, that kind of code that has blocks that look like bricks left randomly around the room, making it very easy for anyone to walk around the place.

Serioulsy, dense code is hard to read and understand. Let’s take this little bit of code as an example:

 

When I run into code that looks like that, this is sort of what I see:

It’s so easy to put that garbage out, like this:

The same happens with collections…

I like this much better:

I always favor using object/collection initializers whenever possible, if that makes the code more compact and easier, more calm to read.

1 Comment