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
- Anonymous
June 03, 2004
The comment has been removed - Anonymous
June 03, 2004
The comment has been removed - Anonymous
June 03, 2004
The comment has been removed - Anonymous
June 03, 2004
The comment has been removed - Anonymous
June 03, 2004
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. - Anonymous
June 03, 2004
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. - Anonymous
June 03, 2004
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 research.microsoft.com 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? :) - Anonymous
June 03, 2004
The comment has been removed - Anonymous
June 03, 2004
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. - Anonymous
June 03, 2004
The comment has been removed - Anonymous
June 03, 2004
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. - Anonymous
June 03, 2004
<A HREF="http://www.panopticoncentral.net/">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. - Anonymous
June 04, 2004
The comment has been removed - Anonymous
June 04, 2004
The comment has been removed - Anonymous
June 04, 2004
The comment has been removed - Anonymous
June 04, 2004
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. - Anonymous
June 04, 2004
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. - Anonymous
June 04, 2004 - 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. - Anonymous
June 04, 2004
Jim:
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;
try
{
enumerator = enumerableObject.GetEnumerator();
while (enumerator.MoveNext)
{
x = (string)enumerator.Current;
//foreach body code
}
}
finally
{
if (enumerator is IDisposable)
((IDisposable)enumerator).Dispose
} - Anonymous
August 18, 2005
Very nice blog. It is very helpful. http://www.bignews.com - Anonymous
June 08, 2009
PingBack from http://cellulitecreamsite.info/story.php?id=3277