Hi, Hugo.

>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.

It is ok, I'm just waiting a friend to go having some lunch. <s>

>>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!)


That's right, but the difference is that what you refer in the using clauses are namespaces who are big buckets of functionality and have a wider application scope. With a with/endwith block you are just shortcutting a local reference and it is not necessarily something anyone can assume about the application.

That said, it is true that can misuse using declarations by overloading your namespaces. I've seen that and advise against unneeded namespace branching.

>> 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.

Just let me note that I'm not loathing with/endwith, but saying it provides very small or null value to me.

>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();
>	};
>

Why is this so different?

using System.Collections.Generics;

var hugo = new .Dictionary<Guid,string>()

hugo.SomeProperty = SomeValue;
hugo.SomeOtherProperty = SomeOtherValue;
hugo.SomeDirtyMethod();

To me this is more clear and less verbose.

>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.

Here you are doing a wrong assumption. To implement with/endwith the compiler HAVE to create a reference (a variable) anyways, so there is no gain at all. That's why I said this is pure syntactic sugar.

This is not the same in VFP where the interpreter can (and indeed does) benefit from creating a local reference on the fly and doesn't have to parse all the hierarchy again (and creating a local variable will incur in a -really negligible- resource increase. This does not apply to compile code.

Again this is not a religious issue, but I guess most C# developers wouldn't want an additional keyword in the language just for a very small -and debatable- value.

As you mentioned before that some things in your code are just pointing to a structural problem, I also think that a frequent need of shortcutting references like this are uncovering some code smells, like deep chaining (most probably due to high coupling) or bloated methods. I never noticed a real need of shortcutting a reference to a temp variable that was not a sign of refactoring needed.

As always, it is nice to debate with you... <s>

Best regards,