Christoph said:
Exactly, Peter. The var keyword saves a lot of extra typing (or using
declarations) that make code less readable. I can't believe that
nobody's able to see past the silly int/string examples. :-(
oh yes we look passed the silly examples. I'll explain why they had to
use var and why it's silly in a strictly typed OO world and why it has
nothing to do with typing.
Say you have a customer and an order table, pretty standard. Order has
a m:1 relation with customer.
Fetching all customers or all orders of a customer is simple, you can
define a customer class or an order class and create instances for each
row you read.
This then could be something like:
CustomerEntity[] customers = myDao.GetCustomers(null);
where GetCustomers simply accepts a filter (here, null) and returns
CustomerEntity instances in an array.
In Sql you can do this:
SELECT C.CustomerID, C.CompanyName, O.OrderID, O.OrderDate
FROM Customers C INNER JOIN Orders O
ON C.CustomerID = O.CustomerID
If you have a customer class and an order class, you're not able to
store this list into a set of object instances. So, instead you have
two options:
1) use an untyped bucket, like a datatable
2) add something to the C# language which creates types on the fly.
In .NET 1.x and 2.x, you'd opt for option 1). In C# 3.0, they have
added option 2) with the 'var' keyword.
The 'var' keyword will create a type for the data returned from a
select, and it's then usable in the code. So if we fetch the list above
with the 4 columns, it would be something like:
var myDynamicList = from customers c, orders o
select c.CustomerID, c.CompanyName,
o.OrderID. o.OrderDate;
(or something, I'm not that familiar with teh new syntax).
Good thing? Well, as you said, let's look passed the silly examples
and look at some real-life scenario.
I have a GUI method which has to display some data, namely a list of
customerid, companyname, orderid and orderdate, very simple. So it
calls the BL tier:
var listToDisplay = myBLObject.GetTheList();
in GetTheList we do:
public var GetTheList()
{
return from customers c, orders o
select c.CustomerID, c.CompanyName,
o.OrderID. o.OrderDate;
}
In the GUI, you now have a list of data, it appears to be typed, as
the compiler knows what's going on, but does the reader of the code?
I don't think so. I mean: is listToDisplay an array, arraylist,
generic collection, 1 object ... what are the properties of the objects
inside the list?
Intellisense will probably show me, but that's not what I have
available when I read the code, I mean, I don't WANT TO fall back on
intellisense to UNDERSTAND code.
Is there an alternative? Sure. Define a simple class with 4 public
fields: CustomerID, CompanyName, OrderID and OrderDate, and create a
list of that. Your BL code then becomes (for example)
List<MyListType> toBind = myBLObject.GetTheList();
hey, all of a sudden we know what the type is in the GUI. Reading the
code, we immediately understand what GetTheList returns: a list of
MyListType objects.
Clarity. This clarity makes it easier to understand code. And when
code is easier to understand, it's less buggy, as the developer easier
spots weirdness in his/her code.
Generics in .NET 2.0 make code more clear, as you don't have to work
with interfaces anymore, you can define strongly typed collections
which are clear. 'var' isn't, it's obscure. And therefore a bad thing.
FB
--
