tags:

views:

1808

answers:

12

VB.NET has the "my" namespace, but how many VB.NET developers actually use it?

  • if you don't, why?
  • if you are using it, why?

I'm considering building a framework for VB.NET, and using the My namespace to plug it into VB seems like a reasonable idea. Is it?

+2  A: 

I mainly use C# and Boo, but when I do use VB.NET I use My namespace quite often. I dont see any reason to not simplify coding. It still retains its readability.

JTA
+1  A: 

I've only used it from a user perspective, I've never plugged anything into it. I consider the My namespace to be some highly reliable, platform-provided, global helper mechanisms. Officially sanctioned shortcuts, really. I might be surprised to see external user or third-party code in there.

As such, I'd encourage a vb framework to define its own appropriately-named namespace instead of latching on to the existing My namespace. Such a framework shouldn't have that "global" feel to it.

Greg D
+5  A: 

I really like the "My" Namespace in VB.NET and I always use it in my WindowsForms applications, because it is very intuitive.

I use primarily these categories:

  • My.Computer: primarily for file system and network purposes
  • My.Application: Version number, current directory
  • My.Resources: Access to resources used by the application residing in resource files in a strongly typed manner.
  • My.Settings: very handy

I think, if your extensions for My of your framework fit well, then many VB.NET programmers would appreciate them.

splattne
+1  A: 

Never used it so far, although I've never actually looked into it either.

I wouldn't advise putting anything into the My namespace yourself, it's much more clear just to lay it out like you would if it were a non-VB framework.

James Gregory
+3  A: 

We do use it in some code, but hesitantly so. It's true that My often helps make code more readable. For example, the Environment.SpecialFolder enumeration curiously lacks a Temp member, whereas My.Computer.FileSystem.SpecialDirectories has one (Path.GetTempPath() will do as well, but is hardly intuitive compared to other special folders).

But My is only beneficial in such cases because the existing APIs are badly-designed, not because My is inherently better. Like JAGregory, I strongly suggest one avoids extending My — or any other kind of global namespace, variable, etc. — whenever possible. The idea just doesn't fit a clean OOP architecture.

Sören Kuklau
It could be argued that you are valuing a clean OOP architecture ahead of productivity and readability?
MarkJ
+2  A: 

I never use the My namespace (I'm a C# developer), but my VB co-worker doesn't as well. I found the My members not necessary, because in many cases, they're counter-intuitive for me, e.g. in my opinion opening a file has something to do with IO (hence System.IO.File) and not with my computer (My.Computer.FileSystem). They always seem so scattered and bunched together.

It's just some re-roll of functionality that is already available otherwise, from all languages. And I don't like depending on Microsoft.VisualBasic.dll when I'm developing for .NET - I always prefer System.*.

And then, it's always kind of limited. I see VB developers struggle with their app when they can't find something in the My namespace, because they can't imagine that you can use something in the System namespace. That of course is not a problem of the My namespace itself.

OregonGhost
A: 

Love the My! Anything that helps me get the job done faster, and provides code for solutions that I don't have to write, the better!

Doug
A: 

I don't use it a lot.

chrissie1
A: 

I'm considering building a framework for VB.NET, and using the My namespace to plug it into VB seems like a reasonable idea. Is it?

If it fits, by all means, use it. Since you didn't offer any further information about your framework it's hard to say. I wouldn't put general-purpose stuff into the My namespace (such as the My.Computer stuff) because there isn't really any advantage to putting it there. However, application-centered helpers fit in well.

Konrad Rudolph
+6  A: 

The purpose of My, as I understand it, is to be an easy shortcut to certain API tasks that are common but hard-to-find or hard-to-use. You probably shouldn't completely subsume your framework under My. (For one thing, C# people using your framework may get grouchy.)

Instead, you should design it as a normal framework. When you're finished, make a list of some common tasks that people might want to use your framework for. See whether any of those could be useful to have under My, especially where there are classes or methods that can be used in a number of ways, but they have one or two really common usages that can be abbreviated with My.

This article shows how to extend My, and it has a section at the end that describes a few design guidelines to follow: Simplify Common Tasks by Customizing the My Namespace

As to your main question, when coding in VB .NET, I use My as often as I can. It reduces a number of operations to one line of code.

Kyralessa
+2  A: 

I've used My in my VB.NET projects, and I don't feel guilty about it. I am primarily a C# guy, but until I transitioned my company to C#, we were a VB shop. In my mind, the My namespace is a nice piece of syntactic sugar. Just as I'm not embarrassed to use C#'s coalesce operator and other sugar, I'm not embarrassed to use VB's sugar, either. (To an extent; I won't use the classic VB functions that .NET still exposes.)

That said, never put anything in that namespace. It's Microsoft's namespace, and just as you wouldn't put anything under System nor Microsoft, don't put anything under My. It will cause confusion later on -- if not for you, then for others who maintain your code. Create your own namespace for your own code.

John Rudy
+1 for "don't extend My". That'll definitely confuse maintainers. And what happens when VB2015 comes out, and Microsoft have added something to My that conflicts with what you've added?
MarkJ
A: 

I use My.Settings and My.Computer often while programming in VB.NET. I particularly enjoy My.Settings as an alternative to using ConfigurationManager.AppSettings when it is appropriate.

I agree with John Rudy about the use of My. It is syntactic sugar that makes life a little more readable.

Stacy Vicknair