will new version of C# let me do this

  • Thread starter Thread starter Gary Brewer
  • Start date Start date
G

Gary Brewer

It would be cool if I could use what I evaulate in an if statement useable
in its code block


for example


if(g>3434) { g=rightHandValue }

g would not be 3434 if it was bigger than 3434



Gary Brewer
 
Gary,

This is easily accomplished.

g = Math.Min(g, 3434);

Hope this helps.
 
It would be cool if I could use what I evaulate in an if statement
useable
in its code block


for example


if(g>3434) { g=rightHandValue }

g would not be 3434 if it was bigger than 3434



Gary Brewer
Click to expand...

g = g > 3434 ? g : 3434;

Translates to if(g > 3434){g = g} else{g = 3434}
 
If I understand correctly, what you are looking for is the introduce
explaining variable (see
http://www.refactoring.com/catalog/introduceExplainingVariable.html). Your
proposal could make code rather difficult to comprehend or maintain:

if (g < 123) {
g = rightHandValue;

if (h < 456) {
h = rightHandValue;

if (i < 789) {
i = rightHandValue + 456 + 123; // back to using magic numbers
} } }

much better (although I still don't know what this code might accomplish):

int gMin = 123, hMin = 456, iMin = 789;

if (g < gMin) {
g = rightHandValue;

if (h < hMin) {
h = rightHandValue;

if (i < iMin) {
i = gMin + hMin + iMin;
} } }

Colin
 
Michael,
Now what *I* wish is that I didn't have to write "Math." in front of the
names of all the math functions.
Click to expand...
In VB.NET you can use Class names on the Imports statement (using
statement).

Which allows:

Imports System.Math ' aka "using System.Math;"

g = Min(g, 3434)

Granted I use it sparingly, as it weakens encapsulation. However I agree
with you Math is one place where I find it useful, especially in a class
full of math functions.

Jay
 
In VB.NET you can use Class names on the Imports statement (using
statement).
Click to expand...

Doesn't VB allow you to use the "With" statement for smaller blocks like
this?

Pete
 
Rob Tillie said:
Nope, you cannot do this. This is completly against the rules of OO
programming. You would have one big mess then.
In Java you can import (using) a specific class, but still you have to
quantify it.
Click to expand...

You do at the moment, but not from the next version of Java. You'll be
able to use something called "static imports" which will precisely
allow you to use static method names without qualifying them.
 
Jon,
So do you think C# will gain the ability. VB.NET has it now!

Its not really an IL issue.

Like any construct, misuse of it does not make it evil. ;-) As I said
earlier for System.Math I find it very useful in VB.NET. Otherwise most of
the time I prefer the 'encapsulation' of needing to prefix with the class
name.

Jay
 
Jay B. Harlow said:
So do you think C# will gain the ability. VB.NET has it now!
Click to expand...

Don't know - I suspect that Java having it will have more bearing on
whether or not C# gets it than VB.NET having it. My guess is that MS
will watch closely what the reaction of Java programmers is to having
it, and make a decision based on that. That's certainly what I'd do,
anyway :)
Its not really an IL issue.
Click to expand...

Of course not
Like any construct, misuse of it does not make it evil. ;-) As I said
earlier for System.Math I find it very useful in VB.NET. Otherwise most of
the time I prefer the 'encapsulation' of needing to prefix with the class
name.
Click to expand...

Absolutely. I can't see myself using it much apart from for
System.Math, and that's the example which is canonically quoted as
well...
 
Jon,
Don't know - I suspect that Java having it will have more bearing on
whether or not C# gets it than VB.NET having it. My guess is that MS
will watch closely what the reaction of Java programmers is to having
it, and make a decision based on that. That's certainly what I'd do,
anyway :)
Click to expand...
I didn't mean to imply that C# needs it because VB.NET has it. ;-)

VB.NET having it was more a demonstration that its not an IL issue. (my line
breaks were off)

I don't know if I would watch the reaction of Java programmers as much, as
try to get a feel from C# programmers if they 'have a need or want' for it.
(if I was MS). And possible the OOP community as a whole.
Absolutely. I can't see myself using it much apart from for
System.Math
Click to expand...
I started writing a Console Application once, where I imported
System.Console. I quickly changed back to Console.WriteLine instead of just
WriteLine for lack of the encapsulation of where WriteLine came from...

Importing System.Console, just didn't feel right ;-)

Just a thought
Jay
 
Jay B. Harlow said:
Jon,
I didn't mean to imply that C# needs it because VB.NET has it. ;-)
Click to expand...

Fair enough.
VB.NET having it was more a demonstration that its not an IL issue. (my line
breaks were off)
Click to expand...

I think it's fairly obvious that it's not an IL issue, as the source
code

using ClassName;
Whatever();

would translate into the same IL as:

ClassName.Whatever();

If the compiler can work out what method should be called, it's very
easy to call it :)
I don't know if I would watch the reaction of Java programmers as much, as
try to get a feel from C# programmers if they 'have a need or want' for it.
(if I was MS). And possible the OOP community as a whole.
Click to expand...

I don't know - I think there are often features which sound great but
don't pan out well in the real world. Watching how things are used (and
abused) in a very similar language (which Java is) can be a good gauge
for this kind of thing.
I started writing a Console Application once, where I imported
System.Console. I quickly changed back to Console.WriteLine instead of just
WriteLine for lack of the encapsulation of where WriteLine came from...

Importing System.Console, just didn't feel right ;-)
Click to expand...

Hmm... I think it would depend on how much console IO I was doing, and
whether or not I was doing *any* other IO. If I wasn't writing to any
files/streams/whatever, I think it would be reasonably unambiguous -
otherwise, I'd avoid it.

As least, that's my guess :)
 
Rob Tillie said:
Nope, you cannot do this. This is completly against the rules of OO
programming. You would have one big mess then.
In Java you can import (using) a specific class, but still you have to
quantify it.
Click to expand...
If the compiler would allow such a thing...
Now, somebody else would have to go through all imported classes to look
where MyFunction is defined. Even for yourself, this can get messy and
unclear pretty quickly.
Click to expand...

But Pascal had the "with" statement for structs (records), and it wasn't a
problem.

Have you ever coded a long mathematical formula full of trig functions in
Java or C#? All that "Math." gets awfully repetitious. Instead of

y = Math.sqrt(Math.sin(x) + Math.cos(x) + Math.tan(y));

(yes, I know this is a silly formula), I'd like to write:

with Math { y = sqrt(sin(x) + cos(x) + tan(y)); }

For the mathematically literate, in the Fortran tradition (which is great
for numerical mathematics), the second of these is decidedly more readable
and less error-prone. Having familiar formulas *look* familiar is
important.

You could even stipulate that if there are nested withs, you can't use
anything that is defined in more than one of them.
 
Michael A. Covington said:
But Pascal had the "with" statement for structs (records), and it wasn't a
problem.

Have you ever coded a long mathematical formula full of trig functions in
Java or C#? All that "Math." gets awfully repetitious. Instead of

y = Math.sqrt(Math.sin(x) + Math.cos(x) + Math.tan(y));

(yes, I know this is a silly formula), I'd like to write:

with Math { y = sqrt(sin(x) + cos(x) + tan(y)); }

For the mathematically literate, in the Fortran tradition (which is great
for numerical mathematics), the second of these is decidedly more readable
and less error-prone. Having familiar formulas *look* familiar is
important.

You could even stipulate that if there are nested withs, you can't use
anything that is defined in more than one of them.
Click to expand...

There are patterns you could use to get around this.

Derive from a MathHelper class which has all those methods
as protected methods, for example.

-c
 
Peter,
The 'With' statement does not allow Class names. The With statement requires
an instance of an object (a variable, not a type).

(as he runs off and double checks) ;-)

Yep, you get a compile error with a 'Type'

'Math' is a type and cannot be used as an expression.

I can see where a localized 'import/with' would be useful...

Hope this helps
Jay
 
I have in fact suggested it (the "with" statement I had in mind) on
gotdotnet.com where they were asking for comments on proposed new features.

To a mathematical programmer, having to put "Math." in front of every trig
function in a big formula is unacceptably verbose.
 
Eric Gunnerson said:
Michael,

You might find this link helpful:

http://www.gotdotnet.com/team/csharp/learn/columns/ask.aspx#with

I do agree that if you're writing expressions, you may spend a lot of time
writing "Math.", but I think that overall, it's a good thing that the class
name is required.
Click to expand...

That's precisely what I don't agree with.

Let's think back to the very first programming language that is still in
use: FORTRAN (1958).

Its name stood for "formula translation" and its selling point was that it
provided a *concise* way to encode mathematical formulas. Instead of

LOAD A
ADD B
STORE C

you could write

C = A + B

and that was one of the great breakthroughs of computer science. Various
advanced functions such as SIN, COS, TAN were included.

If we cannot use user-friendly names for math functions, we lose one of the
handiest techniques of mathematical programming that we've ever had.

If I had to translate some of my astronomy programs from Pascal to C#, I'd
have to add "Math." maybe a thousand times! That's incredibly verbose. I'd
have kilobytes of "Math.".

Yes, I'm old. (Not *that* old, but old enough to remember the days before
Pascal.)
 
I completely agree... and another thing, when .NET first came out, everyone
was going crazy for with using the "using xxx;" statement. I was too, until
I went to look back at other code and I keep needing to look up which
namespace a class was in.

So I've actually gone in the other direction. Unless what I'm doing is basic
(System.IO, System.Data, System.Xml, System.Web) - I SPECIFICALLY put the
fully-qualified namespace and class. I like that, because it's very clear
and there are no assumptions.

I never liked that "with" concept, because it's not clear that when you are
using Cos() whether that's from the "with" up above or whether it's a
function you wrote. And this is the one huge single concept I live by:

"Software bugs are born from assumptions." (I made that up)

In VB6, if you create a variable and it's a "variant" and you assume it be
an int, but since it's a variant it doesn't have to be? That's a bug waiting
to happen. When you create an array and can't remember if it's zero-based or
one-based? You're going to assume, and it will come out as a bug.

Bottom line, although shortcuts (like "with") are good in the short-term, I
don't bother with them - because in 6 months when I have to go work on this
code again, I don't want to try to figure out what I was assuming. I want
everything to be clear, obvious and unambiguous...
 
Back
Top