Re: 'with' statement

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

On Tue, 01 May 2007 15:30:40 -0700, Jon Skeet [C# MVP] <skeet@xxxxxxxxx> wrote:

Michael A. Covington <look@xxxxxxxxxxxxxxxxxxxxxx> wrote:
But there ought to be.

I suspect we'll have to agree to disagree on that front.

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.

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.

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
.

Relevant Pages

  • Re: with statement
    ... I suspect we'll have to agree to disagree on that front. ... And I'll disagree with you both ... be in the language, even if having it would make life a little easier. ... Ambiguity is, IMHO, a poor argument against a "with" statement. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Do People Really Learn Assembly with HLA?
    ... > talk about the expressive ability of the syntax of a human language. ... > contexts, but with the beauty, the expressive ability, of their syntax. ... I must disagree with the thrust of your argument here. ...
    (alt.lang.asm)
  • Re: How to prevent passed value types from being changed
    ... Then I don't see how you come to disagree with my position that the feature isn't *as* useful within a method. ... the XSL language doesn't have _any_ mutable variables. ... That's the only kind of programmer that would also change a method variable from "readonly" to not "readonly" without first considering why the variable was marked that way, and understanding the implications of their change. ... I don't know why you should feel unhappy about the discussion. ...
    (microsoft.public.dotnet.languages.csharp)
  • Just learning lisp - tail recursion issues?
    ... I've always had in the back of my mind that I ought to learn lisp, but the language looks pretty intimidating so I never got round to it. ... (if (zerop size) ...
    (comp.lang.lisp)
  • Re: Forth and Co - The Return of the Jedi
    ... disagree; many take this very much at heart;-). ... Because he wants the flexibility to change the language as he sees ... Chuck) should care that he doesn't like the idea of Standard Forth. ...
    (comp.lang.forth)