This is just plain stupid.

[Mike Labosh]

I can say this:

int commandTimeout =
Convert.ToInt32(ConfigurationSettings.AppSettings["commandTimeout"]);

but I can't say this:
int commandTimeout =
(int)ConfigurationSettings.AppSettings["commandTimeout"];

Or maybe my VB background has caused brain damage, where I can do this:

Dim i As Integer
i = "123" <-- i is now numeric 123

Is there any cleaner way of doing stuff like this without great big long
expressions twice as wide as the code window?
--
Peace & happy computing,

Mike Labosh, MCSD

"When you kill a man, you're a murderer.
Kill many, and you're a conqueror.
Kill them all and you're a god." -- Dave Mustane

 

[Nicholas Paldino [.NET/C# MVP]]

Mike,

You are right, it is your VB background that has caused brain damage.
When you do this in VB:

Dim i As Integer
i = "123"

VB will perform a conversion of the string type into a number for you.

In C#, when you do this:

int commandTimeout = (int)
ConfigurationSettings.AppSettings["commandTimeout"];

You are trying to perform a cast from a string to an int, which can't be
done. You need a conversion.

You can always store the setting in a string variable, and convert it on
the next line. Either way, you have to tell C# what to do. Yes, VB will
give you little advantages like this, but ultimately, that "magic" that it
does for you is going to bite you in the ass one day.

Hope this helps.

 

[Adam Clauss]

int commandTimeout =
Convert.ToInt32(ConfigurationSettings.AppSettings["commandTimeout"]);

This works because it is actually doing a conversion on the object (is it
typed a string? can't remember) returned from AppSettings.

but I can't say this:
int commandTimeout =
(int)ConfigurationSettings.AppSettings["commandTimeout"];

This is casting - casting requires that the object being casted actually be
of the cast type. Casting does not care (or know about) content of things
like strings, only the fact that it IS a string.
Ex:
string s = "123";
int i = (int)s;
will fail because s is NOT of type int, s is of type string.


You could also use int.Parse() instead of Convert.ToInt32().
string s = "123";
int i = int.Parse(s);

(You may want to put a try-catch around the call to Parse in case the passed
string is not actually an int for some reason, typo or something).

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

Before you rant about something try to understand why it's happening , also
knowing that there are a large number of people that not only consider it
normal , but being the correct way of doing it should make yoy think twice.

IMO you should get a better understanding of how a strong typed language
works, what is the difference among casting/conversion methods/implicit
conversion and why they exist in the first place.


cheers,

 

[RCS]

Actually, this isn't that far off. You CAN do this:

int commandTimeout =
Convert.ToInt32(ConfigurationSettings.AppSettings["commandTimeout"]);

You CAN'T do this:

int commandTimeout =
(int)ConfigurationSettings.AppSettings["commandTimeout"];

But you CAN do this (note the extra parens):

int commandTimeout =
((int)ConfigurationSettings.AppSettings["commandTimeout"]);

-or-

int commandTimeout =
int.Parse(ConfigurationSettings.AppSettings["commandTimeout"].ToString());

I don't think those are unreasonable stretches... IMO

Hi,

Before you rant about something try to understand why it's happening ,
also knowing that there are a large number of people that not only
consider it normal , but being the correct way of doing it should make yoy
think twice.

IMO you should get a better understanding of how a strong typed language
works, what is the difference among casting/conversion methods/implicit
conversion and why they exist in the first place.


cheers,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

I can say this:

int commandTimeout =
Convert.ToInt32(ConfigurationSettings.AppSettings["commandTimeout"]);

but I can't say this:
int commandTimeout =
(int)ConfigurationSettings.AppSettings["commandTimeout"];

Or maybe my VB background has caused brain damage, where I can do this:

Dim i As Integer
i = "123" <-- i is now numeric 123

Is there any cleaner way of doing stuff like this without great big long
expressions twice as wide as the code window?
--
Peace & happy computing,

Mike Labosh, MCSD

"When you kill a man, you're a murderer.
Kill many, and you're a conqueror.
Kill them all and you're a god." -- Dave Mustane

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

But you CAN do this (note the extra parens):

int commandTimeout =
((int)ConfigurationSettings.AppSettings["commandTimeout"]);

Are you sure?
Did you test it before posting ?

-or-

int commandTimeout =

int.Parse(ConfigurationSettings.AppSettings["commandTimeout"].ToString());

You do not need to call ToString() AppSettings["Index"] does return an
string.

But yes, you can use Int.Parse to convert a string to an integer




What is your point anyway?
We are talking (bashing) the VB handling of variables types


chers,

 

[tdavisjr]

Instead of placing a try-catch around the call to Parse in .NET 2.0 you
can use TryParse and returns a bool whether or not it can be done.

if( int.TryParse(s) )
{
int i = int.Parse(s);
}

The way you won't have to worry about an exception being thrown.

 

[RCS]

Sorry, one more set of parens needed...

int commandTimeout =
((int)(ConfigurationSettings.AppSettings["commandTimeout"]));

Glad to help!

Hi,

But you CAN do this (note the extra parens):

int commandTimeout =
((int)ConfigurationSettings.AppSettings["commandTimeout"]);

Are you sure?
Did you test it before posting ?

-or-

int commandTimeout =

int.Parse(ConfigurationSettings.AppSettings["commandTimeout"].ToString());

You do not need to call ToString() AppSettings["Index"] does return an
string.

But yes, you can use Int.Parse to convert a string to an integer




What is your point anyway?
We are talking (bashing) the VB handling of variables types


chers,

 

[Bruce Wood]

What we're talking about here is a difference in philosophy.

VB.NET carries on in the tradition of languages like PL/I, BASIC and
earlier versions of VB. It says:

"Just assign whatever to whatever and I'll do my best to convert it.
I'll get it right 98% of the time. The other 2%... oh well, sorry."

C# carries on in the tradition of C / C++ / Java and, if I recall,
Pascal. It says:

"There is no magic. You must explicitly state what you want to do."

On the one hand, all of the background magic / help that VB.NET gives
you certainly is convenient. However, what most here are arguing is
that it does not _simplify_ programming. Yes, you have to type fewer
characters, but then you're letting the language make some decisions,
and they're not always obvious decisions or the right decisions.

Ultimately, the overall tone of VB / VB.NET: that the languages do lots
of work for you behind the scenes, leads to sloppy programming
practices, IMHO. VB programmers tend to be prototypers: slap something
together, run some quick tests, throw it into production, deal with any
fallout.

C# is a more exacting language, and C# programmers tend to be
correspondingly pickier and more exacting programmers.

This is _not_ to say that tossing prototypes into production is always
a bad thing. I've seen it work for companies. However, as I said, it's
a difference in philosophy. To a die-hard VB programmer I'm sure that
C#'s pickiness and exactitude looks stupid, just as to a die-hard C#
programmer the sloppy, anything-goes nature of VB.NET looks stupid.

 

[Willy Denoyette [MVP]]

You may add all parens you like, it won't compile.
You simply can't cast a string to int, guess that's what Ignacio meant to
say.

Willy.

Sorry, one more set of parens needed...

int commandTimeout =
((int)(ConfigurationSettings.AppSettings["commandTimeout"]));

Glad to help!

Hi,

But you CAN do this (note the extra parens):

int commandTimeout =
((int)ConfigurationSettings.AppSettings["commandTimeout"]);

Are you sure?
Did you test it before posting ?

-or-

int commandTimeout =

int.Parse(ConfigurationSettings.AppSettings["commandTimeout"].ToString());

You do not need to call ToString() AppSettings["Index"] does return an
string.

But yes, you can use Int.Parse to convert a string to an integer




What is your point anyway?
We are talking (bashing) the VB handling of variables types


chers,

 

[Kevin Spencer]

Hi Bruce,

I agree with you. However, I will take it one step further. The fact that
VB.Net and other "magic" programming languages allow one to do things which
are technically incorrect, and fix them behind your back, not only makes for
sloppy programmers, but also ignorant ones. Why bother learning the
technical details when you don't have to? Well, I can tell you why: Because,
assuming that one is interested in improving one's lot in life as a
programmer, one will encounter more and more difficult problems, and run
into situations where understanding the technical details is not only
convenient; it's downright necessary. So, languages like C, C++, Java, and
Pascal actually do the developer a favor by being more strict, much like a
strict parent raises disciplined and successful children. You have to learn
more to use these languages, and that knowledge brings you more power. So, I
wouldn't put it down to a simple "difference" in philosophy. 1 is certainly
"different" than 2, but 2 is also "more" than 1. And if I had the
opportunity to receive 2 dollars or 1 dollar, I would rather know which was
more, than just the fact that they were "different." IOW, "different" and
"equal" are 2 different concepts. The philosophy of the "non-magical"
languages can be demonstrated to be qualitatively better overall for the
improvement of the developer's skills.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
You can lead a fish to a bicycle,
but it takes a very long time,
and the bicycle has to *want* to change.

 

[Stefan Simek]

Instead of placing a try-catch around the call to Parse in .NET 2.0 you
can use TryParse and returns a bool whether or not it can be done.

if( int.TryParse(s) )
{
int i = int.Parse(s);
}

The way you won't have to worry about an exception being thrown.

You meant if (int.TryParse(s, out i))

 

[Guest]

What we're talking about here is a difference in philosophy.

VB.NET carries on in the tradition of languages like PL/I, BASIC and
earlier versions of VB. It says:

"Just assign whatever to whatever and I'll do my best to convert it.
I'll get it right 98% of the time. The other 2%... oh well, sorry."

C# carries on in the tradition of C / C++ / Java and, if I recall,
Pascal. It says:

actually, C and C++ have very lax rules when it comes to type casting. (not
talking about type conversion, but implicit casting) type safety is not
really guarantteed.

 

[Guest]

you can add another 10 sets, and it still won't work.

there is no implicit or explicit conversion between int and string. and
there's a huge difference between casting and calling methods like
Int32.Parse or Convert.ToInt32. namely it demonstrates the concept of type
safety.

Sorry, one more set of parens needed...

int commandTimeout =
((int)(ConfigurationSettings.AppSettings["commandTimeout"]));

Glad to help!

Hi,

But you CAN do this (note the extra parens):

int commandTimeout =
((int)ConfigurationSettings.AppSettings["commandTimeout"]);

Are you sure?
Did you test it before posting ?

-or-

int commandTimeout =

int.Parse(ConfigurationSettings.AppSettings["commandTimeout"].ToString());

You do not need to call ToString() AppSettings["Index"] does return an
string.

But yes, you can use Int.Parse to convert a string to an integer




What is your point anyway?
We are talking (bashing) the VB handling of variables types


chers,

 

[Bruce Wood]

Well, yes, but C won't quietly convert a string to an integer for you,
or vice versa. Granted it's not as strict as C#, but it's not VB.NET,
either.

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

Well, yes, but C won't quietly convert a string to an integer for you,
or vice versa. Granted it's not as strict as C#, but it's not VB.NET,
either.

No, C is the opposite of VB: " I assume you know what you are doing even if
it does not looks right to me"


cheers,

 

[Guest]

Well, yes, but C won't quietly convert a string to an integer for you,
or vice versa. Granted it's not as strict as C#, but it's not VB.NET,
either.

It doesn't convert string to integer, but it does many things just as
problematic with regards to type safety, and C# is designed to address the
shortcomings of VB as much as the shortcomings of C. It's a stretch to
suggest that C is better than VB when dealing with types.

 

[RCS]

Oh - yeah, you're right, my mistake - for int and string, it won't convert.
But I think that makes perfect sense, there is no way you could trust that
the supplied string had just numbers in it, that's why there is int.Parse()!

You may add all parens you like, it won't compile.
You simply can't cast a string to int, guess that's what Ignacio meant to
say.

Willy.

Sorry, one more set of parens needed...

int commandTimeout =
((int)(ConfigurationSettings.AppSettings["commandTimeout"]));

Glad to help!

Hi,



But you CAN do this (note the extra parens):

int commandTimeout =
((int)ConfigurationSettings.AppSettings["commandTimeout"]);

Are you sure?
Did you test it before posting ?

-or-

int commandTimeout =

int.Parse(ConfigurationSettings.AppSettings["commandTimeout"].ToString());


You do not need to call ToString() AppSettings["Index"] does return an
string.

But yes, you can use Int.Parse to convert a string to an integer




What is your point anyway?
We are talking (bashing) the VB handling of variables types


chers,