"My" | Tech Off | Channel 9

I've just read this:

Navigate the .NET Framework and Your Projects with "My"

and I didn't like it. Although I love easy-to-use software, I think this is just a worthless effort. The way to help developers understand the framework is to improve documentation (as discussed here), not to create yet another vast library of wrapper classes and functions. Why?

- Now, you have to learn two major namespaces (As if the framework itself isn't enough). As I understand it, "My" is used to handle some 'frequently used code', and is certainly not going to provide wrappers for the entire framework.

- Even if it did, I would want to learn the framework structure itself, not just a language extension..

- Since, as I understand it, "My" is a layer on top of the framework, won't it slow down applications even more?

Your thoughts?

themaffeo

Hmmm. I have mixed feelings – I’ll have to wait until I actually use it to pass judgment. I do agree that providing two different accesses to the same technology could end up being more confusing than anything else, however, as one who will routinely use intellisense to find classes I want to work with, the My namespace might provide an easier way to do that.

As for slowing things down, I will almost guarantee you that the overhead of calling an extra method (which as the article pointed out is something you were likely to do anyway) will come at no significant performance cost. There have been numerous tests that show in-process cross-component calls are very efficient. Besides, chances are if you were developing an application that needed those 20 extra CPU cycles you won’t be the type of programmer who would be using the MY namespace anyway. (In fact, you would probably be developing at a lower level to squeeze out those cycles)

Like I said, I need to use it myself to see how ‘useful’ it will be. One thing I will say though, is that the MSDN documentation for these procedures most defiantly should have a ‘see related’ link to the actual framework methods it encapsulates.

Lwatson

One thing in all this that I welcome will be the printer extensions in the MY namespace. I realize that printing now in .Net is perhaps a better way than the old printing under VB 6 but the My namespace will bring back some of the ease that the old printer device used to have. I applaude this part of the effort as many of our clients want our apps to print directly when printing is called for. The complexities of crystal reports deployments are just getting in the way for them. The My printing functionality will be great for those kinds of things.

bwill

Then the library isn't targeted at you. Its intended for the opportunistic programmer who perhaps doesn't have time to learn the breadth of the framework, but does appreciate the fact that most of the common stuff can be accessed with 'My' and Intellisense.

I don't work on the 'My' team, so don't take my comments as the final word; just my understanding. I'm am sure that the 'My' team would love it if everyone (and not just a subset of developers) found the 'My' tool useful.

prog_dotnet

Visual Basic "Whidbey" provides new features for rapid application development that aim to improve productivity and ease of use while delivering power. One of these features, called the My object, provides access to information and default object instances that are related to the application and its run-time environment. This information is organized in a format that is discoverable through IntelliSense and logically delineated according to use.

The top-level members of the My object are exposed as objects. Each object behaves similarly to a namespace or a class with Shared members, and exposes a set of related members.

The three central objects that provide access to information and commonly used functionality are My.Application, My.Computer, and My.User. You can use these objects to access information that is related to the current application, the computer that the application is installed on, or the current user of the application, respectively. The following examples demonstrate how information can be retrieved using My.NET.

' Displays a messagebox that shows the full command line for the
                    ' application.
                    MsgBox(My.Application.CommandLine)
                    ' Displays a message box that shows the operating system installed 
                    ' on the current computer.
                    MsgBox(My.Computer.OperatingSystem.ToString)
                    ' Displays a message box that shows the user name of the current user.
                    MsgBox(My.User.UserName)

In addition to retrieving information, the members exposed through these three objects can also allow you to execute methods related to that object. For instance, you can access a variety of methods to manipulate files or update the registry through My.Computer. My.Application allows you to change the culture for your application or create a simple application log, and My.User exposes a method that determines if the current user is in a specified group. The following examples demonstrate how these methods can be called.

' Changes the current culture for the application to Jamaican English.
                    My.Application.Culture.ChangeCulture("en-JM")
                    ' Creates a new Event Log named MyLog.
                    My.Computer.EventLogs.CreateLog("MyLog")
                    ' Displays a message box that shows whether or not the current 
                    ' user is a member of the 'Managers' group.
                    Msgbox(My.User.IsInGroup("Managers"))

Default Object Instances Provided by My.Forms, My.DataSources, and My.Webservices

The My.Forms, My.DataSources, and My.Webservices objects provide access to forms, data sources, and XML Web services used by your application. They do so by providing collections of default instances of each of these objects. A default instance is an instance of the class that is provided by the runtime and does not need to be declared and instantiated using the Dim and New statements. The following example demonstrates how you might have declared and instantiated an instance of a Form called Form1, and how you are now able to get a default instance of this Form through My.Forms.

' The old method of declaration and instantiation
                    Dim myForm As New Form1
                    myForm.Show
                    ' With My.Forms, you can directly call methods on the default instance
                    My.Forms.Form1.Show

The My.Forms object returns a collection of default instances for every Form class that exists in your project. Similarly, My.DataSources provides easy access to every DataSource that exists in your project, and My.Webservices provides a default instance of the proxy class for every Web service

------------------------------

my.application.object

The properties exposed by My.Application return data that is associated only with the current application. Note that no system-level information can be altered with My.Application.
Provides access to members that are related to the current application.

Property	Description
CLRVersionInUse	Returns the version of the common language runtime that is used by the current application.
CommandLine (Windows Forms only)	Returns the complete command line of the application as a String.
CommandLineArgs (Windows Forms only)	Returns a collection that represents the command-line arguments for the application. The executable file name is not included in this collection.
CompanyName (Windows Forms only)	Returns the CompanyName associated with this application.
Culture (Windows Forms only)	Provides access to the current culture and UI culture for the application, as well as methods to change them.
Description (Windows Forms only)	Returns the Description associated with this application.
EnvironmentVariables	Returns a collection that represents the environment variables for the application.
FileName	Returns the file name of the application executable file.
Folder	Returns the folder that the application executable file resides in.
LegalCopyright (Windows Forms only)	Returns the LegalCopyright associated with this application.
LegalTrademark (Windows Forms only)	Returns the LegalTrademark associated with this application.
Log	Provides access to the application log, which allows you to log entries to an event log, a text file, or the debugging window.
ProductName (Windows Forms only)	Returns the ProductName associated with this application.
SpecialFolders (Windows Forms only)	Provides access to special folders that are used at an application level.
Title (Windows Forms only)	Returns the Title of this application.
Version (Windows Forms only)	Returns the Version of this application.

-------------------------------

my.computer object

The properties exposed by My.Computer return data that is associated with the current computer upon which the application is deployed, as determined at run time. Note that no design-time information is retained.Provides access to members that are related to the computer on which the application is running.

Property	Description
Audio (Windows Forms only)	Provides access to the audio system of the computer, and provides methods for playing .wav files.
Clock	Returns a reference to the system clock, which allows you get the current local time and Universal Coordinated Time (Greenwich Mean Time).
FileSystem	Provides access to the file system on the local computer, and supplies methods for a variety of common file system tasks, such as reading from, writing to, or moving a file.
Keyboard (Windows Forms only)	Provides information about the current state of the keyboard, such as what keys are currently pressed, and provides a method to send keystrokes to the active window.
Mouse (Windows Forms only)	Exposes information about the format and configuration of the mouse installed on the local computer.
Name	Returns the computer name as a string.
Network	Provides access to information about the current state of the network, and supplies methods to ping other computers.
OperatingSystem	Provides information about the operating system installed on the local computer.
Registry	Provides access to the registry of the local computer, and supplies methods for common registry tasks, such as creating and deleting keys, and changing key values.
Screen (Windows Forms only)	Returns the System.Windows.Forms.Screen object that represents the current screen installed on the local computer.

--------------------------------------

my.user object

The properties and methods exposed by My.User return data that is associated with the current user of the application, as determined at run time. Note that no design-time information is retained.

Provides access to members that are related to the current user.

Property	Description
DisplayName	Returns the display name of the current user as a String.
DomainName	Returns the domain name of the current user as a String.
SpecialFolders (Windows Forms Only)	Provides access to special folders that are related to the current user.
UserName	Returns the user name of the current user as a String.
WindowsRoles	Returns a collection of strings that represent each group of which the current user is a member.

Method	Description
IsInGroup	Returns a Boolean that expresses whether the current user is a member of a specified group.

..............................

Cronan

This is a great idea. Using it might be a little like recording a macro (back in the days).

How do I do such-and-such?
Find it in My
Read the docs and find out which is the wrapped framework class
Use the framework class in the future

Anything that aids accessibility is a good thing, as long as it doesn't force everyone to do the same thing.

ktegels

bwill wrote:

Then the library isn't targeted at you. Its intended for the opportunistic programmer who perhaps doesn't have time to learn the breadth of the framework, but does appreciate the fact that most of the common stuff can be accessed with 'My' and Intellisense.

I don't work on the 'My' team, so don't take my comments as the final word; just my understanding. I'm am sure that the 'My' team would love it if everyone (and not just a subset of developers) found the 'My' tool useful.

So we can alias "My" to "LazyCoderTypes" then right? Smiley

cjbreisch

I can't think of a single good thing to say about it. It will make converting between C# and VB.NET harder. It "dumbs down" VB again when I thought the whole point was to make all the .NET languages functionally equivalent. It means that if I really want to hire a C# developer, I'm going to have to actually hire one, and not hire a VB.NET developer and teach him/her syntax. It forces my company to pick a language and stick to it, where now we're trying to do whatever makes sense given customer constraints and developer comfort.

Actually, I'll be even more blunt. Resources allocated to this at Microsoft would be better allocated elsehwere on the VS 2005/.NET Framework 2.0 projects. Anywhere else. Can you say "edit and continue" for C#? How about "refactoring" for VB.NET? I think you can.

Now, if you wanted to make it as easily accessible and usable by C# developer then it might have purpose. Of course, I'd still have to ask why we need two frameworks.

This is a complete waste of time and $ by MS at a time when there are many other issues of significant priority and urgency getting ignored.

Chris J. Breisch, MCSD, MCDBA

Steven

Hmmm....

I'm actually on the My team (aka the Visual Basic team), so I'll try to provide a little clarification. Also keep in mind that we haven't shipped the beta yet, so we're certainly interested to know how we can improve things.

The My object is not meant to be a "wrapper" on the framework. It's more of a "speed dial" into the most commonly used application functionality, so that you can look in one place for the things that you use the most.

A good example is My.Resources. In VS 2003, it's a little cumbersome to load resources from your assembly. In VS 2005, we use a generator provided by the framework team that creates a thin, strongly typed class that loads resources for you. So if you have a bitmap called "BackgroundImage", for instance, then you can just write the line of code "Me.BackgroundImage = My.Resources.BackgroundImage". There are no strings to type in your code, and you get full intellisense on your resource names. My.Forms and My.Settings work in a pretty similar way.

There are some cases like My.Computer.FileSystem where we point at things that will exist in the framework, and in fact we had a discussion today about how we can make those functions more easily available to the other languages.

We've been presenting this to VB user groups on our current VB World Tour, and the feedback so far has been pretty positive. Of course your mileage may vary...

Steven Lees
Microsoft Visual Basic Team

Cronan

cjbreisch wrote:

... It "dumbs down" VB again when I thought the whole point was to make all the .NET languages functionally equivalent. ...

I'm interested to know how you think adding a namespace changes the VB language specification. While I agree that the languages need to produce equivalent IL, I disagree that VB should strive to be C#. What made VB6 so successful was the degree to which it abstracted the complexities of COM development away. I agree, some mistakes were made, but making VB.Net an easier place for the "part-time" or "beginner" programmer to work cannot be a bad thing.

Speaking as someone who has converted from VB6 to VB.Net to C# over the past 2 ¹/₂ years, I don't agree with you.

Cronan

Steven wrote:

I'm actually on the My team ...

Steven

I assume that anyone will be able to add this namespace and program against it?

Lwatson

cjbreisch wrote:

Now, if you wanted to make it as easily accessible and usable by C# developer then it might have purpose.

So you are saying that unless its C# its not worth anything? That is precicely the attitude that irks me the most about some developers. (If its not {insert you language paradigm here} its below me and I want nothing to do with it). I will grant you that historically VB coders have had a perhaps deservedly bad reputation as a whole, VB.Net is not your fathers VB. There is a whole lot of development going on there that has merit. These abstractions are welcome in that space.

cjbreisch

Lwatson wrote:

So you are saying that unless its C# its not worth anything?

No, that's not what I'm saying at all. That's entirely too narrow of a focus. I'm saying that unless it's worth doing for ALL of the .NET languages that MS is providing, then it's not worth anything.

I don't like differences between the tools. I never have. I was very excited when VS 2002 eliminated nearly all of them, and I can't think of a single good reason to add more back in.

cjbreisch

Cronan wrote:

I'm interested to know how you think adding a namespace changes the VB language specification.

I don't recall saying that it did. What it does do is make it so that someone who is a VB .NET coder can not easily convert their code and their mindset to C#. Also, consider someone working in C# who has a problem. He finds a solution on the net, but it's in VB.NET. He can't easily use this solution.

If you think this won't happen, you don't remember Visual Studio 6. I spent quite a bit of time getting MFC code to work in VB6 and vise-versa. I spent an awful lot of time converting MS samples written in C++ to work in VB or VBA. I nearly pulled my hair out several times, and would've without Steven Roman's excellent book (shameless plug) "Win32 API Programming with Visual Basic".

At the risk of being redundant, I don't see a single good reason for putting this in, and I've yet to see/hear a good argument for it's existence from anyone, including MS.

Lwatson

cjbreisch wrote:

No, that's not what I'm saying at all. That's entirely too narrow of a focus. I'm saying that unless it's worth doing for ALL of the .NET languages that MS is providing, then it's not worth anything.

On the surface I am inclined to agree on that point. However if both sets of syntactic collections are to provide all of the same functionality without any compromise on that functionality set then why have two sets of syntactic collections?.

Are there not things being bandied about in the C# camps that are not going to appear in the VB camp?

Some stuff I have seen no mention of appearing in the VB camps are Public/Private Gets/Sets for example. There are others. I do agree that there is a danger of 'Oh Yeah, well my language can do THIS' one upmanship that is counterproductive at best.

Is it though, still early? Is it possible that some of this stuff would make release on boths sides of the fence. Afterall would it not be simple enough to impliment support for the other half after CLR support was added for the first half?

cjbreisch

Lwatson wrote:

On the surface I am inclined to agree on that point. However if both sets of syntactic collections are to provide all of the same functionality without any compromise on that functionality set then why have two sets of syntactic collections?.

Now, that's a good point. Perhaps the best I've heard so far. No, I don't want all the languages to be identical. VB, for example, has a feature that VB developers really like, "with", that has no corresponding feature in any other .NET language that I know of (Aside -- that brings to mind my favorite real life interview question: "When would you use 'with'" A: "Never." Not the answer that they were looking for, but I backed it up. Smiley

) C# has "using",which VB does not. But what I don't want is a divergence between languages for no good reason. Is there a good reason for the "My" namespace? If there is, is there any good reason not to have it in all .NET languages? If there's no good reason to add the "My" namespace to C#, then what's the justification to add it to VB? One could argue that the reason for "with" in VB and "using" in C#, and hence "My" in VB is that VB is still at a "higher" level" and C# still at a "lower" level. Personally, I don't think that there's much difference, but I can buy that argument for smaller features, but not something big like a new namespace.

One of your examples, different access levels for getters and setters is something I personally would like to see in C#, but you brought it up in a VB context. I often want to make my getters be public, and my setters be protected, or even protected internal ("Protected Friend").

I do agree with your point that it's still early, but I don't think it's possible that "My" will end up anywhere other than VB. That doesn't agree with what I've heard so far. It's possible that I've been misled or that I've misunderstood, but I don't think it likely.

I just don't think that the justification for "My" has been made publicly or internally at Microsoft, and I have to question why. It's never a good idea to add a feature just beause it's "neat". MS (and most of us) has a long history of bloat/featurism.

As a matter of fact, I will go one step farther. I challenge anyone at MS to make that justification here and now. Why is "My" a needed feature, and if it's needed, why is it not needed in any other language than VB? Why is it "more" necessary than other features that have already been cut out of the VS 2005 release due to time/resource constraints?

If no one from MS can make these justifications here (or at least internally), and I honestly don't think they can, then they need to re-examine this feature and how, or if, it will be added to the feature set.

Steven

Cronan wrote:

Steven

I assume that anyone will be able to add this namespace and program against it?

Pretty much. My is just a normal namespace in your project, so there's nothing that prevents you from adding additional components to that namespace, and then coding against them.

One of the goals of the My object, though, is to make it easy to find the things that you use most often, so you wouldn't want to go adding a ton of stuff in there.

Steven

Steven

A few details in response to some of the comments above:

VB 2005 does allow you to have different levels of accessibility on getters and setters, which people would usually use for having a public get and a private/protected set. (Not that it really matters, but we were the first MS language team to add this to the Whidbey release.)

VB 2005 also includes the Using statement (to release disposable resources), generics, operator overloading, and unsigned types, among other things. Still no "unsafe" code blocks though.

One thing that a lot of people don't realize is in VB 2003 is the ability to declare a variable in a For or For Each statement. You can write:

For i As Integer = start To End

and

For Each ctrl As Control in ControlCollection

It's something I think more people would use if they realized it was there.

There's more info about VB Whidbey on the MSDN VS 2005 dev center.

Steven

cjbreisch wrote:

As a matter of fact, I will go one step farther. I challenge anyone at MS to make that justification here and now. Why is "My" a needed feature, and if it's needed, why is it not needed in any other language than VB? Why is it "more" necessary than other features that have already been cut out of the VS 2005 release due to time/resource constraints?

For justification, I'd refer you back to Duncan's article. (See the link at the top of this thread.) He's summarized it pretty well. For what it's worth, almost every VB developer that I've talked to, including those who use both VB and C#, is really excited about the My object. I think a big part of this is because of the way that we've built the feature: we're not trying to hide the framework, just make it easier for you to get the most out of it. It's pretty hard to use a framework function if you don't even know that it exists.

I think your "why is it not needed in any other language" question is a good one. We've heard from a lot of developers that they really like the fact that C# and VB are so similar, and that it's easy to switch back and forth. We're not going to back away from that, and Whidbey demonstrates that pretty clearly. Big enabling features like generics are in both VB and C#. Each team has it's own priorities, though, so it's unlikely to see us both always doing exactly the same things at exactly the same time.

chockenberry

has anyone definitivly said the My Object WILL NOT be available to the c# developers? If it is just another namespace in the framework, I would think we could reference it if it is a subset of the system namespace. If is a subset of the Microsoft.VisualBasic namespace I beleive you can discoverand use it through reflection. If is a new language feature, than its not really a namespace so much as a language keyword and compiler object. In that case, then yes, it would not be available to the c# developer. Even in that case it will just be a matter of time before some does write a wrapper class for it so that c# developer can consume the same features. Correct me if I am wrong. Back to my original question... has anyone actually said definitivly that c# will not be able to use the my object??