Claudio and Martín,

First, forgive me for the length of this message, and for wasting your time, I know is such a small issue that does not warrant all the typing and reading, but, what can I do, I am a curious person.

>if one can't see the begin of the "with" block, just seeing .Something in code is totally unclear.

One could argue that if you can not see the begin of the with block, it is clear that your method needs refactoring for it is too long <g>

>However, in the "using" case, anybody who's been working in .NET knows that the Console class resides under the System namespace, so keeping System.Console seems redundant to me.

Well, you are just using my boring simple example to avoid the issue <g>
What I think is that the Using directive is potentially more problematic than the with statement; and I see a lot of similitud between both, so I do not understand people who loath the with and love the using. For example, you talk about the visibility of the with, but, isn't it worse with Using? After all a with statement could/should be confined in a relatively short snippet of a short method, while the scope (sorry if my choose of words is not the best) of the Using is global for the module you are writing, thus having more chances of not being visible, of course you can use tricks like tooltips or what not, but still remains as a bigger issue than the with, and there other "issues", in my opinion, with the Using that are not present with the with statement, but I will not bore you more with them, but what you said about the Console class might hint you <g>. (That said, do not get me wrong, even after what I said before, which was half joking, I really like the Using!)


> Also, having fully-qualified types may get trick if the hierarchy goes down three of four levels, and if the type is a generic type taking, say, two parameters...

I agree, but the fact is that I also see the same benefit in the with structure, that apparently neither you nor Martín seems to appreciate (among other people, of course), and that is why I am asking why the loath to the with, because knowing Martín, I am sure I am missing something and I want to learn.

For example, following yours, and without paying attention as if a real case or not, why you guys think something like this is not worthless?

with new System.Collections.Generic.Dictionary<Guid,string>()
	{
		.SomeProperty = SomeValue;
		.SomeOtherProperty = SomeOtherValue;
		.SomeDirtyMethod();
	};

I know that you guys would preferr to just assign a variable and then go from there, but... if you do not like the "with" structure, then you should be punished and suffer writing all the code, as simple as that <g>. Seriously, assigning a variable to do the job is trading run time resources (Memory and Execution Time) for nothing (well, you could argue about legibility, but as with the case of the with structure, legibility is in the eye of the programmer, so some may not like to see the same variable written all over 10 lines). I know that nowadays a couple of bytes here and there and a couple of nanoseconds here and there is nothing, but I still believe the concept of creating a variable just for personal aesthetics and/or reduce the typing is wrong. Now, you might compare it with assigning values to intermediate expressions in a formula, but even there you can point to other advantages, like easier debuging or cleaner logic that are not present in the point in case.

Now, don't get me wrong, I am far from purist, and I bet that if my coworkers read this they will laugh very hard, for they know my crappy code, is simply that I seem to be missing something else and I would like to know, because I do find the with structure neat. It might not even need to be part of the language, if the goal is to keep the language trim, it can be just a pre-processor directive of some sorts (not sure about the feasibility of something like that thou)


Cheers and appologies again.