A rant
-
I wonder... Most of the same problems could be created by a C# programmer as well.
var this_is_a_very_long_variable_name_damn_it;OK, casting may be a little different. ;)public string SecretPassword { private get; set; }// NO SE EXACTAMENTE COMO FUNCIONA ESTO, REVISALO BIEN:D It often seems to me that CPians are bashing VB developers just because it's VB. It's the same kind of hatred that many people have towards Microsoft, because it's, well... Microsoft.Pawel Krakowiak wrote:
Most of the same problems could be created by a C# programmer as well.
Yes, that's true. However, the average C# programmer will create less problems than the average VB.NET programmer. And, geeeh, I'm not even saying anything about real VB (versions 1 to 6) developers.
Pawel Krakowiak wrote:
var this_is_a_very_long_variable_name_damn_it;
That is not C#, but JavaScript. I hate all scripting languages... well, almost all, I actually like Python (but not as much as I do like C++).
Pawel Krakowiak wrote:
It often seems to me that CPians are bashing VB developers just because it's VB.
No. What I hate is late binding. If I didn't have to type
Option Strictto enforceDirectCasts, I would actually like VB.NET. And if it had anUnsafedirective, I would like it even more. By the way, are you Polish? I'm trying to learn Polish, but I don't find any sources to learn from.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.
-
What's so bad about writeonly properties? They do have some use.
"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
If you want to provide a class with some data, you pass that data in through a constructor or method parameter. By using a write only property you fuzzy the usage of the class. Assuming you want to provide a nice clean api for your class, you would keep it so that data was passed into the class as it is required. By allowing that data to be passed in whenever the caller feels like it, you reduce the strictness of the classes contract. It's not so much that a write only property is itself bad, it's just that there is no sensible reason to use a write only property instead of a method parameter. Regarding the example with the password - Remember that 'private' is only a construct of the language, it is not a feature of the CLR, or a security measure. a write only property will not stop a malicious user from reading the property out of the class with reflection, so this is not a good example of a use for write only properties Maybe I'm wrong, maybe there is a sensible and good use for a write only property. I'm happy to consider any suggestions you have. I just I can't think of any, and my instinctive reaction is that it's use will only cause disjointed code. [Edit: 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]
Simon
modified on Friday, September 19, 2008 3:59 AM
-
Pawel Krakowiak wrote:
Most of the same problems could be created by a C# programmer as well.
Yes, that's true. However, the average C# programmer will create less problems than the average VB.NET programmer. And, geeeh, I'm not even saying anything about real VB (versions 1 to 6) developers.
Pawel Krakowiak wrote:
var this_is_a_very_long_variable_name_damn_it;
That is not C#, but JavaScript. I hate all scripting languages... well, almost all, I actually like Python (but not as much as I do like C++).
Pawel Krakowiak wrote:
It often seems to me that CPians are bashing VB developers just because it's VB.
No. What I hate is late binding. If I didn't have to type
Option Strictto enforceDirectCasts, I would actually like VB.NET. And if it had anUnsafedirective, I would like it even more. By the way, are you Polish? I'm trying to learn Polish, but I don't find any sources to learn from.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.
leonej_dt wrote:
That is not C#, but JavaScript.
It is C#[^]. Though in C# it's still a strongly typed variable, but from the code readability perspective it looks much like Visual Basic's Dim. I use implicitly typed variables with LINQ.
leonej_dt wrote:
By the way, are you Polish?
Yes.
leonej_dt wrote:
I'm trying to learn Polish, but I don't find any sources to learn from
I doubt I could be of much help, I was taught by parents / people around and at school. :P
-
leonej_dt wrote:
That is not C#, but JavaScript.
It is C#[^]. Though in C# it's still a strongly typed variable, but from the code readability perspective it looks much like Visual Basic's Dim. I use implicitly typed variables with LINQ.
leonej_dt wrote:
By the way, are you Polish?
Yes.
leonej_dt wrote:
I'm trying to learn Polish, but I don't find any sources to learn from
I doubt I could be of much help, I was taught by parents / people around and at school. :P
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 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.
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?
-
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.
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.
-
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.
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 intTo 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.
-
There is nothing that a WriteOnly property can do that a method can't. And I'm too used to write code like...
// start and end are both pointers start = end = NULL;... that the idea of a variable that I can write but can't read is TOTALLY weird. Besides,WriteOnlyproperties were only called ONCE for each object, strangely enough, always before doing the first useful thing with it. Code looked like this...' GAAAH... VB.NET Dim JustQuiteLongVariableName As New UndocumentedClass JustQuiteLongVariableName.Parameter1 = A JustQuiteLongVariableName.Parameter2 = B + "C" JustQuiteLongVariableName.Parameter3 = "D" JustQuiteLongVariableName.DoSomethingUseful() JustQuiteLongVariableName.DoSomethingElsePerhapsItWillBeUseful() JustQuiteLongVariableName.Dispose()... when it could have been...With New UndocumentedClass(A, B + "C", "D") .DoSomethingUseful() If .EnsureNextThingIsUseful() Then .DoNextThing() .Dispose() End WithTo 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.
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
-
If you want to provide a class with some data, you pass that data in through a constructor or method parameter. By using a write only property you fuzzy the usage of the class. Assuming you want to provide a nice clean api for your class, you would keep it so that data was passed into the class as it is required. By allowing that data to be passed in whenever the caller feels like it, you reduce the strictness of the classes contract. It's not so much that a write only property is itself bad, it's just that there is no sensible reason to use a write only property instead of a method parameter. Regarding the example with the password - Remember that 'private' is only a construct of the language, it is not a feature of the CLR, or a security measure. a write only property will not stop a malicious user from reading the property out of the class with reflection, so this is not a good example of a use for write only properties Maybe I'm wrong, maybe there is a sensible and good use for a write only property. I'm happy to consider any suggestions you have. I just I can't think of any, and my instinctive reaction is that it's use will only cause disjointed code. [Edit: 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]
Simon
modified on Friday, September 19, 2008 3:59 AM
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
-
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
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 FoosTemp = StringReturningFunction(x,y,z)
oFoo.SetValue(sTemp)or
Dim oFoo as New Foo
oFoo.WriteOnlyProperty = StringReturningFunction(x,y,z)