Connecting with my inner child. (ok, it was actually someone else’s child)

Last night i got a chance to see the new son james of one of my friends from school and work. He's all of 4 days old, but he's completely adorable and i wish the entire family a wonderful future.

I thought that while I was on the topic of cute, adorable new things that smell slightly like poo it might be a good time to talk about VB and to mention a feature that they have that really caught my attention recently. (i kid, i kid, VB isn't that new). I'm talking specifically of the new "My dot" feature. The name comes from the new system that VB has for providing you with many common conveniences when you type the in "My" followed by a dot.

The theory is quite sound. Specifically, the BCL frameworks are incredibly powerful and allow you to do may things, however they come with so much complexity and abstractions that finding out how to do very simple tasks is sometimes quite difficult. To help solve that the "My." system would wrap much of the complexity behind simple convenience classes that would allow you to have a one stop shop to both discover the environment and then perform common useful actions on it.

I come from a java background myself and I can attest to how difficult this kind of system can sometimes be. For example (and please tell me if I'm out of date or wrong) i recall that just creating an XML parser could be quite annoying at times. I had to create a DocumentFactoryBuilder which would produce a DocumentFactory which i could then parse a stream out of to get an actual Document. As a very OO minded developer I understood the model and I appreciated the power it gave me to drop in other parsers, to change parameters, and to dictate where i wanted to generate the XML document from. However, sometimes I just wanted to parse a file and i didn't like the hoops i had to jump through. Other areas where I felt the same were clipboard management and Drag-and-Drop. Both were areas that exposed an incredible amount of power to the programmer, but also made it quite confusing how to do a simple task.

I've heard similar things said about the BCL, and while I don't have have enough experience with it yet I can understand where people are coming from. However, rather than just sitting there commiserating with unhappy people the VB team decided to do something about it, and they came up with the "My." system (hereto referred as My.). 'My' is a special 'thing' in VB now that is somekind of an amalgam of a namespace and a type. Inside this typespace they've provided many convenient ways to access information that is relevant to you and to give you quick access to perform many simple operations without a lot of conceptual overhead involved.

Here's what the first view looks like:

as you can see it looks partially like a type with a few properties like "computer, application, user", and it looks partially like namespace with a nested namespace "Resources" (which I'll talk about at another time). If we expand down into the Computer property we can see useful ways to access things like audio or even the network:

How useful is that? If you just want to know if the network is available bam so easy. If you want to download a file, trivial. If you want to receive a notification when the system loses/gains network access, it's also provided. Every single thing in there is useful and allows me to do things without incurring the enormous overhead of learning the ins and outs of so many different APIs.

If i want to use the clipboard to simply push/pull an image, it's there:

Now it goes without saying that you can't do everything from here. That's not the point of My.. If you need to do more you can just use the actual BCL apis that My. sits on top of. However, if you're writing an app around a certain domain and you just need to do something simple in a different domain this allows you to do so while remaining focussed on what you're doing. Heck, I'd love my app to say "Welcome Cyrus" when it starts up, but I'd have no idea how to do that. With My. I could just use:

I think this idea is a fantastic one and i think VB developers are going to love it. I'm curious about some aspects of it, like whether or not it's extensible. But I'd imagine the VB team is going to see how people feel during beta1 and will use that feedback to drive the final feature.

I also think that C# developers are going to be asking why don't we have this feature. What do you think? Is this something you would want, or am i just being wowed with smoke and mirrors? Is this a model that all APIs should potentially strive for. A full robust API view that allowed you to do almost anything you would expect in that domain; and an extremely simplified wrapper view that exposed the most common types/operations/behaviors so you could quickly dive in and get what you wanted.


Edit: Adding example of what My.Computer looks like:

Comments (21)
  1. Ivan Towlson says:

    No, I don’t think you’re being wowed with smoke and mirrors. One of the goals expressed by the ASP.NET team in particular has been "reduce the amount of code you have to write in common scenarios by [outrageous number] percent." The "My" thing does exactly that — encapsulates the 90%-of-the-time case so people doing the usual thing don’t have to pay the full flexibility tax.

    There *is* a danger that encapsulating this stuff means some developers will be lost at sea when the 10% time comes — not having built up a bit of experience with the "real" API they may find their first encounter with it is an obscure edge case instead of a well-documented "normal" case. Whether this is a serious issue is something that I suspect could only be resolved by user testing.

    Certainly I’d like something like this in C#. The "My" keyword feels very un-C#-ish — maybe Elvis would prefer a simple unadorned Computer.Xxx, User.Xxx, etc. — but other than that I do feel somewhat envious.

  2. Ivan Towlson says:

    Oh, and one other benefit that struck me — My.Xxx plus Reflector is likely to make a great source of sample code for the "real" API.

  3. 仪表 says:

    Cyrus raises a chortle: "I thought that while I was on the topic of cute, adorable new things that smell slightly like poo it might be a good time to talk about VB."

    it’s great!

  4. Jay Glynn says:

    Smoke and mirrors. Where it becomes a problem is that there are generally several ways to do something. Not all are part of the "My" feature, so instead of researching the API and looking at alternatives, the average dev will just use what is given to them even though it may not be the best option.

  5. Radu Grigore says:

    It sounds like a good use of the Facade pattern. I would probably love it. An alternative you might want to consider is to provide one facade for each namespace instead of one big facade for the whole API. Writing System.Xml.CommonActions.ParseFile("bau.xml") makes it clear where you should look for documentation about ways to customize it. OTOH, having all facades named CommonActions might lead to annoying name clashes while using customized names can make them harder to find.

  6. Kristof Verbiest says:

    Personally I don’t like it. Now you have two API’s to learn: the simple ‘My’ and the ‘real’ API. And if your code starts out simple but gets more complex, you may have to migrate from the ‘My’ API to the real APIs. I think this is very confusing.

    The problem that ‘My.’ tries to solve could be solved by a smart collection of code snippets for all these frequently occuring tasks. Instead of using the ‘My.’ API, you just insert the correct code snippet. It would be almost as easy to use, but you would see the actual APIs being invoked, and it would be possible to extend on this code if you wanted to do something more advanced.

  7. Andreas Häber says:

    It sure looks nice for RAD which VB is for, but it should stay there too. I’m looking much more forward to the new features in C#, like refactoring etc.

    The difference between the languages shouln’t just be the syntax (like in VB you get begin/end and in C# you have {}). Rather use the time to add more real-time features to C# which the ‘standard’ RAD VB developer won’t need, but which IMHO is more likely a C# developer could need (see Polyphonic C# at for more about this.. AFAIK this is included in C-Omega now). The language is just a tool and you should select the appropriate tool for the job…

    Maybe you could look more at taskin in Ada95 and get some of the nice ideas from there? 🙂

  8. Flatlander says:

    Cyrus raises a chortle: "I thought that while I was on the topic of cute, adorable new things that smell slightly like poo it might be a good time to talk about VB." Like Cyrus, I am impressed with and

  9. I don’t have a problem with it for VB. I actually kind of like it, as long as it is kept in that space. However, I do believe that this space should be made available to all of .NET, not just through VB. Instead of it being something between a namespace and a type, why not have it be some sort of a namespace/type in the Microsoft.VisualBasic namespaces, accessible through the Microsoft.VisualBasic.dll assembly? This way, if anyone outside of VB wanted to use it, then they could, but wouldn’t have to. It would be something easily available to VB developers from the start, and optional for all others.

  10. Smoke and mirrors my friend… don’t pay attention to the man behind the My curtain.

    My may be well and good for those who dabble in the evil that is VB… but don’t start infecting a perfectly good language like C#. *shiver*

  11. Adam Miller says:

    I would like to know how it’s implemented. I mean if it’s truly a wrapper of those functions written in another dll, then i should be able to reference it just fine from my C# app.

  12. Len Weaver says:

    <A HREF="">Paul Vicks</A> blogged about the ‘My’ namespace a few weeks ago. Basically, most of the My namespace resides in the Microsoft.VisualBasic.dll assembly – so it is available to c# devs. Some of the features of ‘My’ also some from the VB compiler though. My.Forms is apparently created when an assembly is compiled, so My.Forms would not be available to c# unless/until the c# compiler team adds support for it.

  13. Jim Gunkel says:

    One of the problems of My is that it will force the developers to learn yet another API which does nothing but duplicate existing functionality. Even C# guys will have to deal with it. How many times have you been searching google news or reading a .NET book and the example is in VB instead of C#. Normally not a problem, but once My starts invading all of the VB examples, C# developers will have to search elsewhere for examples.

    If My actually ends up extending the functionality of the current API then you are leading to API rot which will create confusion for VB developers over which method to call for speed, feature or maintenance reasons.

    That said, I do like the idea of My from a simplicity point of view. Writing code in VS.NET and C# has been a pleasure since you can focus more on the business of the code rather than the mechanics. Anything to improve that is a good thing for developers, even the power guys.

    I would prefer that My was an access point to a repository of code snippets rather than a class wrapper around commonly used class APIs. Maybe even so much so that there isn’t an actual My class defined anywhere, it is just an Ide/compiler helper that ends up sticking the code snippets into the code stream before it is compiled. Then for those 10% of cases where the simplicity of My doesn’t cut it, you could right click on your line of My code and expand it to the original code snippet (with calls to the traditional .NET APIs) and extend the code from there.

  14. Daniel O'Connell says:

    I dislike the snippet idea because I don’t want language features that rely on the IDE to be useful in C#(FWIW, I dislike region for this same reason, but its much less of an issue that something like linking My to snippits would be). It works ok in VB becaues VB and the IDE have been tied together for a long time now, but I dislike the idea in C#.

    Beyond that, the snippet library doesn’t solve the problem of learning two API’s, you end up learning two api’s anyway and then you end up with the possibility that code using My won’t port safely or would have to be recompiled if something like a serious security vulernability shows up, niether of which are particularly desirable(not to mention you are asking for massive methods like this, what happens when 9 or 10 My calls results in 10 or 15 lines of code a piece? You end up writing methods that are nothing but a call to a My method, which *completely* defeates the point, or methods that are massive as far as IL goes. This is even worse without a decent refactoring system).

    Code snippits are an IDE feature, not a language feature.

    Frankly, I think people are looking for a reason to bash VB rather than examining the problem. It is a good idea, its just not a C# idea. I for one don’t think its going to bother VB developers at all, as it stands they use a considerable api outside of the BCL and I rarely see that much confusion and really how often do you look at vb code for a solution where you can’t find C# code to do it? Beyond all that, some of the dynamic features of My(My.Forms for example and IDE linking to My.Settings) are of considerable value when you are developing client applications(its probably less of an issue for core code) and it should bring things back towards VB6’s ease of developing a UI.

    And for that matter folks, how often does it really matter that the framework method is one call faster? If it does you are using the wrong platform. These performance concerns are getting out of hand. It isn’t nessecerily wise to not think about performance, but being upset over *every* little *possible* micro-reduction in performance is really quite ridiculous. Real speed enhancement generally requires enough knowledge of the system that its downright silly to assume the developer will get confused between a My call and a framework call. In any situation where performance is going to be an issue there is going to be a *series* of calls that have to be understood. I agree that knowledge of what the My call does may be helpful, but chances are if the person can handle the series of calls to get the performance he wants he can determine what the My method does as well.

    As for realtime, IMHO, .NET in its current form isn’t a good canidate for many realtime systems(it might work in some, but I’d be hesitant to rely on it without an awful lot of assurance, correct me if you know of some documentation on it). You would need a realtime framework with a controllable garbage collector(schedulable with time constraints and that can be aborted if need be) which is probably far enough away that examining C# extentions for realtime processing isn’t useful quite yet. Some of the hardening work in Whidbey should help its canidacy, but I think that more needs to be done.

    Also, since realtime is really not that common of a field, I don’t think that adding realtime constructs to the language is considerably less useful than general purpose extensions would be(although it would make a logical offshoot language, rtC# perhaps).

  15. Cleve Littlefield says:

    I have long wondered when they introduced the idea why this is not coming for C# as well. Screw the people who say that this introduces confusion. If it make stupid redundant code easier and quicker, I am all for it.

    Give us this feature! Please dont give any VB stuff that C# doesnt get, and vice versa. You are just encouraging the language wars. Edit and Continue too…

  16. Wow. Lot’s of responses 🙂

    Backwards order!

    Cleve: If VB has everything that C# has and C# has everything VB has… then why have two langauges at all? Each language is trying to target and maximize performance for specific developers with different needs and different styles.

    Not only that but there are very very finite resources here. While I would like to pretend that i work a nice 20 hour week and go to the beach the rest of the time, it simply isn’t so. Every single day between now and when we have to ship is filled with work that has to be done.

    VB creates features that they think are the most valuable for their customers and C# does the same for ours.

    I think langauge wars are good. Why? Because I’ve never met a single langauge that was good enough for every task. However, when one langauge realizes that something is a good idea it can spread out into other languages. Likewise when one langauge makes a mistake others can learn and decide to not integrate those features in. It’s this kind of differentiation that leads to advancements in languages and to better development systems for all programmers.

  17. To All: Even though you could load the Microsoft.VisualBasic dll, it would not be the same experience. I mentioned how the My. construct was treated both as a static class and as a namespace. THat simply couldn’t be done with the current C# language. You would have to get specialized langauge/compiler to do that.

    However, taking just the covenience class aspect of it would be quite possible.

  18. Jim Gunkel says:

    * Code snippits are an IDE feature, not a language feature. *

    Yes, snippets in a simplified form are an IDE feature (and I don’t really like any implementation that I’ve seen either). But there are very popular C# compiler features that expand code into a template and when used right can be very useful. A few examples of this are using() which expands to exception handling and an IDispose call and foreach() which expands to a for statement and enumerator calls.

  19. Daniel O'Connell says:


    I don’t consider using and foreach to be expansions. They are language keywords that operate over the given interfaces and are *equivilent to* what you are suggesting. Its not that the compiler takes a foreach call and generates the literal C# code for it and then compiles that; it generates code that works something like a while(although as long as it is functionally correct, I don’t think there is a requirement to be semantically like a while). There is a world of difference between a keyword which performs a given action conceptually and a keyword which generates a code snippet. If you start calling any keyword in a language a template, its pretty hard to stop. After all, an if is just a template for IL, isn’t it?

    Anyway, FWIW, I think foreach generates code similar to a while statement, not a for. Enumerators have no given upper bound so a for isn’t an appropriate pattern.

    foreach (string x in enumerableObject) { … }

    should result in something similar to

    IEnumerator enumerator;



    enumerator = enumerableObject.GetEnumerator();

    while (enumerator.MoveNext)


    x = (string)enumerator.Current;

    //foreach body code





    if (enumerator is IDisposable)



  20. miglena says:

    Very nice blog. It is very helpful.

Comments are closed.

Skip to main content