A rant

[leonej_dt]

Pawel Krakowiak wrote:

It is C#[^].

Sorry, excuse me for my ignorance. I have VS2k5 at home.

Pawel Krakowiak wrote:

Though in C# it's still a strongly typed variable

Then why not state explicitly its type? What do language designers have in their minds?

Pawel Krakowiak wrote:

but from the code readability perspective it looks much like Visual Basic's Dim.

To me, code readability means being as semantically expressive as possible.

Pawel Krakowiak wrote:

I use implicitly typed variables with LINQ.

I will stick to TableAdapters.

Pawel Krakowiak wrote:

I doubt I could be of much help, I was taught by parents / people around and at school. :P

Nevermind. Thanks, anyways.

To those who understand, I extend my hand. To the doubtful I demand: Take me as I am. Not under your command, I know where I stand. I won't change to fit yout plan. Take me as I am.

[Pawel Krakowiak]

leonej_dt wrote:

I will stick to TableAdapters.

I despise DataSets and everything related, I just rewrote whole data access code in one of my projects from DataSets/TableAdapters to LINQ to SQL this week. :P Now I have less lines of code, easier maintenance of the schema, got rid of several stored procedures but still don't have SQL spaghetti in my code, can change connection strings on the fly (this was very very annoying with typed DataSets). In overall I think that C# 3.0 is a major improvement and it rocks. I try to upgrade all projects whenever I get a chance to benefit from lambda expressions and extension methods. I love the language. :rolleyes: By the way - where does your interest in the Polish language come from?

[Pete OHanlon]

leonej_dt wrote:

Though in C# it's still a strongly typed variable Then why not state explicitly its type? What do language designers have in their minds?

It's a .NET3.5 thing. It allows you to create anonymous types in things like Linq. For instance:

var f = from c in MyDataContext.Items
where c.DateCreated > inputDate and c.DateCreated < terminationDate
select new { UserID = c.UserId, Created = c.DateCreated, TotalPosts = c.PostCount };

foreach (var p in f)
{
Console.WriteLine("{0} {1} {2}", p.UserID, p.Created. p.TotalPosts);
}

(Apologies for the badly named variables, but this is an example only). :-D

Deja View - the feeling that you've seen this post before.

My blog | My articles | MoXAML PowerToys

[leonej_dt]

If the designers had good taste, anonymous types would only be legal when using LINQ. But, according to the documentation, this is also valid C#: var i = 100; // implicit int

To those who understand, I extend my hand. To the doubtful I demand: Take me as I am. Not under your command, I know where I stand. I won't change to fit yout plan. Take me as I am.

[Paul Conrad]

leonej_dt wrote:

... that the idea of a variable that I can write but can't read is TOTALLY weird.

It is weird. Only thing I can think of for a purpose is just for assigning values to a variable used internally by a class, but even that, some method could do for you, as well.

"The clue train passed his station without stopping." - John Simmons / outlaw programmer "Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon "Not only do you continue to babble nonsense, you can't even correctly remember the nonsense you babbled just minutes ago." - Rob Graham

[leonej_dt]

Simon Stevens wrote:

I suppose, like any construct (e.g. Goto) even if it's considered bad in 99% of cases, there probably are one or two situations where it makes for cleaner code

Even goto has its uses. An elegant implementation of an in-order traversal of a tree can be implemented using goto. (The only way that can be achieved without gotos has some redundant code.) Here's the code: // BST: binary search tree struct NODE; typedef NODE *LPNODE; struct NODE { /*...*/ LPNODE left, right; }; typedef void(*action)(node); void iterate_bst(LPNODE cur, const action &a) {   if (!node) return;   CStack<LPNODE> stack; // defined somewhere else   stack.push(NULL); // very important push_parents:   // Go to last left descendant and save its ancestors in a stack.   while (cur.left)   {     stack.push(cur);     cur = cur.left;   }   do   {     // Do something to the current node.     (*a)(cur);          // If there is a right child, process it before     // return to the current node's parent.     if (cur.right)     {       cur = cur.right;       goto push_parents;     }     else       cur = stack.pop();   }   while (cur); } :-D But WriteOnly properties do not serve ANY purpose.

To those who understand, I extend my hand. To the doubtful I demand: Take me as I am. Not under your command, I know where I stand. I won't change to fit yout plan. Take me as I am.

modified on Friday, September 19, 2008 11:44 AM

[Scott Barbour]

Yes, a method could do that for you (you could also use a method to read a variable, so why have properties at all?) I'm sure there are a number of situations where there is a property that you want to write to, but not read from. It comes down to a matter of how elegant you want the code to be. For example, which of the following two appears to be more elegant (some variables not declared for simplicity)?

Dim sTemp as String
Dim oFoo as New Foo

sTemp = StringReturningFunction(x,y,z)
oFoo.SetValue(sTemp)

or

Dim oFoo as New Foo

oFoo.WriteOnlyProperty = StringReturningFunction(x,y,z)