G
Guest
Hello,
In vb.net there is a with statement, Is there are similar constructor in c#?
In vb.net there is a with statement, Is there are similar constructor in c#?
A
Andy
No, there is not.
M
Mark Rae
M
Michael A. Covington
Andy said:
But there ought to be.
As well as a genuine "case" statement (allowing operands of any type) to
replace the current "switch" statement, which is a deformed relic of the
influence of Fortran upon C in 1972 or so.
J
Jon Skeet [C# MVP]
Michael A. Covington said:
I suspect we'll have to agree to disagree on that front.
I'd rather write a descriptive variable name and put that in front of
each statment than have the ambiguous (when there are multiple levels
of "with") dot on its own.
Yes, a better switch statement would be very welcome. Groovy allows
some rather cool things on that front. Quite whether the fast
performance of the C-style switch can be matched (even for the simple
cases) by a more flexible switch is a matter for research etc. I'd
happily give up the performance in 99% of the cases in favour of the
flexibility.
P
Peter Duniho
And I'll disagree with you both (but agreeably so, I hope).
I disagree that "there ought to be" in C#. As the article Mark referred
to points out, we lived just fine without a "with" statement in C and
C++. It's just not that important a construct to argue that it *ought* to
be in the language, even if having it would make life a little easier.
Intellisense in VS makes the usefulness of "with" even less, since it
usually only takes a handful of keystrokes to type in the longest of names
(exceptions including when you've got a lot of long names that are mostly
the same...a bad idea anyway, IMHO
).I do see utility in the "with" statement. I just don't find it so
compelling as to demand its inclusion in the language.
Ambiguity is, IMHO, a poor argument against a "with" statement. The
article Mark referred to brought up the question of ambiguity between a
field and a local variable. Well, as VB does, so too could C# just
require slightly different syntax for a field than a local (so you can
easily tell the difference between ".Text" and "Text"). As far as nested
"with" statements go, there are two easy solutions: either disallow nested
"with" statements altogether, or only allow access to the inner-most
"with" statement in any block of code.
I'd prefer the former, but if the language did the latter but the compiler
emitted a warning similar to that used when hiding a local variable, that
would be fine with me too.
I don't really see ambiguity as a significant or unresolvable problem,
with respect to having a "with" statement.
Pete
M
Mark Wilden
There's an easy solution to the problem of nested "with"es - "don't do
that".
I think a stronger objection is that you shouldn't be making a lot of calls
one after another to a single object (in general).
///ark
G
Guest
I've seen this particular question come up at least 4 or 5 times in the last
year or so, and I have to agree. "With xyz ".... is simplyunnecessary in a
concise and elegant language like C#. Hard core classic VB programmers who
are resistant to change are usually the ones who harp on this (among other
silly issues).
Peter
--
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
Short urls & more: http://ittyurl.net
year or so, and I have to agree. "With xyz ".... is simplyunnecessary in a
concise and elegant language like C#. Hard core classic VB programmers who
are resistant to change are usually the ones who harp on this (among other
silly issues).
Peter
--
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
Short urls & more: http://ittyurl.net
M
Michael A. Covington
Peter Bromberg said:
What I'd much rather have is a concise notation for mathematics.
Programming as we know it originated with Fortran (Formula Translation),
which allowed you to write such things as:
Y = SIN(X)**2 + COS(Z)**2
In C#, if I'm not mistaken, we're now stuck with
y = Math.Pow(Math.Sin(x),2) + Math.Pow(Math.Sin(z),2)
which is a great deal farther from normal mathematical notation. I know
it's nice and object-oriented, but something valuable has been lost.
It could have been worse. They could have given us:
Object.Assign(ref y,
Math.Add(Math.Pow(Math.Sin(x),2),Math.Pow(Math.Sin(z),2)));
If + has special status as a math operator, then why not ** and the Math
functions?
J
Jon Skeet [C# MVP]
Michael A. Covington said:
Yes - this is a problem which Java solved using "static imports" - you
can specify either particular members or "all static members" from a
particular class, and then the class name doesn't need to be specified.
You'd just have:
y = Pow(Sin(x), 2) + Pow(Sin(z), 2);
Definitely something to be used with great care, but handy. In fact, I
wanted this just yesterday, for testing purposes...
I like a small language, personally. I don't think most people use the
power operator often enough to make it worth including in the language,
myself.
D
DeveloperX
There's an easy solution to the problem of nested "with"es - "don't do
that".
I think a stronger objection is that you shouldn't be making a lot of calls
one after another to a single object (in general).
///ark
I completely agree with this. One of my bug bears is coming across
code that looks like:
Kitten.MoveFrontPaw(Left);
Kitten.MoveBackPaw(Right);
Kitten.MoveFrontPaw(Right);
Kitten.MoveBackPaw(Left);
instead of:
Kitten.Walk();
and then the above travesty is needlessly repeated in about 30
locations normally with comic variations of Paw ordering.
M
Michael D. Ober
DeveloperX said:
Your example is multiple methods being called. I agree with you for
methods. However, try this:
Kitten.Color = "Black"
Kitten.Eyes = "Green"
Kitten.Fur = "Long"
These are properties of a Kitten. In general, they cannot be incorporated
into a single property.
Mike.
M
Michael D. Ober
Peter Duniho said:And I'll disagree with you both (but agreeably so, I hope).
I disagree that "there ought to be" in C#. As the article Mark referred
to points out, we lived just fine without a "with" statement in C and
C++. It's just not that important a construct to argue that it *ought* to
be in the language, even if having it would make life a little easier.
Intellisense in VS makes the usefulness of "with" even less, since it
usually only takes a handful of keystrokes to type in the longest of names
(exceptions including when you've got a lot of long names that are mostly
the same...a bad idea anyway, IMHO
I do see utility in the "with" statement. I just don't find it so
compelling as to demand its inclusion in the language.
Ambiguity is, IMHO, a poor argument against a "with" statement. The
article Mark referred to brought up the question of ambiguity between a
field and a local variable. Well, as VB does, so too could C# just
require slightly different syntax for a field than a local (so you can
easily tell the difference between ".Text" and "Text"). As far as nested
"with" statements go, there are two easy solutions: either disallow nested
"with" statements altogether, or only allow access to the inner-most
"with" statement in any block of code.
In VB, the with statement is really nothing more than telling the compiler
"Make a temporary, unnamed, local variable for me." As for ambiguity in
nested with statements, only the inner most with statement allows access to
its properties without specifiying the variable name. Is a with statement
useful - definitely. Is it a must have, no.
There is no ambiguity with the VB with statement. It can, however, be less
useful than expected, especially when nested.
Mike.
M
Michael A. Covington
But when we use it, it really helps correctness if our formulas can *look*
like formulas!
Be careful when asking for a language that doesn't cater to
mathematicians... you might get COBOL.
A
Andy
No, there should not be. It doesn't add anything that you can't
already get with a simple statement. It doesn't make code more
performant, and it doesn't make code any more readable. In other
words, it adds no value whatsoever.
What if said objects don't have comparison operators? Most classes
don't define == or even .Equals, which means that switch would operate
on the default implementation, which compares references. Not very
useful. Also, if switch isn't powerful enough for you, you can also
use if - else if statements. Honestly, switch is a rarely used
construct I've found.
A
Andy
Actually I find it a good argument. It makes the language (and hence
the compiler) more complex. Adding a bunch of complexity for no real
gain isn't a great idea in my opinion.
J
Jon Skeet [C# MVP]
On May 2, 2:26 pm, "Michael D. Ober" <[email protected]>
wrote:
This is normally done once, when constructing the object - which is
why C# 3.0 has syntax specifically for this case.
Jon
wrote:
This is normally done once, when constructing the object - which is
why C# 3.0 has syntax specifically for this case.
Jon
J
Jon Skeet [C# MVP]
I think that's an argument for allowing user-defined operators (not
just overloading of existing ones), which is attractive in some senses
but makes things more complicated.
I don't think C# is trying to target *every* developer on the planet.
It doesn't need to be all things to all people. It's much better (IMO)
to cater very well for the more common cases, making the rarer
situations a bit harder (but still perfectly doable).
Jon
P
Peter Duniho
I know. And as I stated, that is the solution to the ambiguity that I
prefer.
I said that too.
I know there's no ambiguity. That's why I said it's not a problem.
Pete
P
Peter Duniho
My point is that "ambiguity" as a debating point is a non-starter. A
"with" statement is only ambiguous if the language designer allows it to
be, and there's no reason for them to.
Yes, introducing a "with" statement increases complexity, but that's true
of anything you include in a language. If "complexity" in and of itself
were an argument against inclusion, then no computer language would do
anything.
And keep in mind, there are plenty of people who would debate whether a
"with" statement offers "no real gain".
Pete