>>>>Good point. Left me wondering if they considered a different keyword for the using statement. 'wrapping', 'disposing'; ?
>>>>Actually 'disposing' sounds good - descriptive of what it does.....
>>>
>>>My point is that it is an unnecessary directive, you can write the same program without it, more verbose, but more readable as it answers unambiguously the question raised by Nicholas
>>
>>Certainly more verbose. But don't think it's more readable. Say I have a custom class library:

namespace Viv.SomeApp
>>{
>>    public static class File
>>    {
>>        public static void ReadAllLines(string s)
>>        {
>>        }
>>    }
>>}

Options if I need to use this and System.File.IO in same code:

using VFile = Viv.SomeApp.File;
>>using System.IO;
>>public class Program
>>{
>>    public static void Main()
>>    {
>>        //Without using
>>        Viv.SomeApp.File.ReadAllLines("xxx");
>>        System.IO.File.ReadAllLines("xxx");
>>
>>        // With using
>>        VFile.ReadAllLines("xxx");
>>        File.ReadAllLines("xxx");
>>    }
>>}

I prefer the 'using' version.
>
>Well, readability might not be the right word, I give you that, as you might think that too much verbosity is not as readable, but using fully qualified names removes ambiguity, which in my opinion makes it much more readable. As a bonus, it reduces the need of re-factoring (strictly talking about the re-factoring due to the miss-use of the using directive as we are discussing it).
>
>Back to your example, in the end you just aliased the namespace, the only thing I will say is that, in my opinion, it is also a source of some issues, whatever small they are, they are unnecessary, as they do nothing for the end product. Let me give you some examples of the issues I see:
>
>- You aliased Viv.SomeApp.File as VFile, now another developer in their code aliases it as CustomFile, or VivFile or ourFile or whatever, lastly a third developer is going to use/review/fix/upgrade/whatever both of your files, I see it as confusing
>- Ambiguity. If you do not know from where something comes, it will take you more time to find out information, granted, with internet access this is generally not an issue but still... lets say you are reviewing a big system that has several namespaces that you are not familiar with (and for argument sake, you are not in an IDE, lets say you are using some DIFF tool) now from where does this darn method (lets say ReadAllLines) come from when I googled it the first 100000 results are for IO.File!
>- Sharing partial code makes things more complicated, just like we see in this thread, you see this in a lot of blogs and examples.
>- You have also scoping issues for the using directive where you might end up using something that was not your intention
>
>Anyways, I am not trying to force my views on you, I am just justifying why I rather type extra, all those things are little things, but are they really necessary?
>
>As a side note, and I am not saying you were one, many people here despised the WITH clause in fox and one of the arguments was that it was better to explicitly qualify the objects, back then verbosity was not an issue... (I know some advantages and disadvantages or with, my point here is only related to verbosity as it is the issue here)
>
>I promise not to bother you any more with this subject, I wasted enough of everyone's time.

Not a waste of time - you make some fair points. It would certainly be better if sample code used fully qualified namespaces. And, to a certain extent, FQNs would be better if code was being edited using an IDE other than VS. Within VS, given intellisense and the ability to access a type just by hovering over the code, I'm happy with using and aliases.

Maybe the WITH statement in VFP was a step too far - the same result, one step removed, could be obtained by using a temp variable to reference a nested object....