Welcome to MSDN Blogs Sign in | Join | Help

Allow using up to the object level.

Darren sent me a few questions. Normally, I'd put these in the C# FAQ, but I've decided to answer them here for now. They may migrate to the FAQ in time.

 

*** allow "using" up to the object level

 

I use VB sometimes, and one of the things I really love about it is that if I create a static class (say CommonFunctions)  I can import SMB.Common.CommonFunctions.  All static functions are now part of just my standard namespace.   I like it!  Object purists may have collective apoplexy, but I'd prefer to remain agnostic and believe that we shouldn't have to qualify absolutely everything we do.  Some functions really do belong in the global namespace (and all languages have some) - and it would be really nice as a developer to be able to make our own.  It's there in VB - can we have it in C#?  Please? :)

 

I think it's unlikely that we will do this. I understand the desire to be able to do this, but one of our major goals is to keep the language readable. Features like this and C++'s macros mean that to read code, you don't just have to understand the base language, you also have to understand all the additions that have been added by the author of the current project.

 

So, yes, it is true that writing Math.Sin() is longer than just writing Sin(), but it's also much clearer to any reader of the code.

Published Thursday, April 22, 2004 8:58 AM by ericgu
Filed under: ,

Comments

Thursday, April 22, 2004 9:22 AM by Joe White

# re: Allow using up to the object level.

Cool.

I have a Delphi background, and while it's sometimes kind of nice that Delphi allows global functions, it's more often tedious -- since I have to hunt through a dozen different source files to find the one that actually implements that procedure. I've come to appreciate the C# way, both of making you scope methods to a class, and of giving you an error if you import two namespaces with the same class name.
Thursday, April 22, 2004 9:42 AM by J. Daniel Smith

# re: Allow using up to the object level.

And can't you already write something like

using SMB.Common.CommonFunctions = Globals;
Globals.Func1();

at least that's shorter than SMB.Common.CommonFunctions.Func1();
Thursday, April 22, 2004 12:27 PM by mearls@hotmail.com (Michael Earls)

# RE: Allow using up to the object level.

I just recovered from a small bout of apoplexy. Now that I have my wits about me, I must say that I appreciate that C# will not support this. It's a great idea, and the feature is pretty darn nice to have, but while I'm taking the extra keystrokes to ensure that my code is of the correct case, I don't mind also qualifying the precise purpose of my code.

I think it's good that we can do this in VB.NET, though. I probably won't because it triggers my acute apoplexy syndrome, but it's nice to know I can when I want to. All I have to do is change languages.
Thursday, April 22, 2004 1:03 PM by Corrado Cavalli

# re: Allow using up to the object level.

Totally agree wit Eric,
I prefer a clearer statement vs less keystrokes (and Whidbey intellisense has been improved a lot on C#...)
Thursday, April 22, 2004 1:49 PM by John

# re: Allow using up to the object level.

In my own code I would never do something like this:

using SMB.Common.CommonFunctions = Globals;

I think it just leads to unnecessary confusion. Why give the same thing two names?

I also always qualify my namespace, so if I'm calling a public static method I use the name of the class (even if I'm calling from within that class), and I always use 'this' infront of instance methods.

Doing it this way also means that IntelliSense pops up without needing to press CTRL-SPACE (which I find slows me down) and removes any ambiguity.

John.
Thursday, April 22, 2004 2:30 PM by John Rusk

# re: Allow using up to the object level.

Coming from a Delphi background, one thing I do miss in C# is the readability of mathematical expressions. E.g.

a = Round(Sin(y));

is easier to read that

a = Math.Round(Math.Sin(y));

With the first one, you can read it more "fluently" in your head.

So, from a readability point of view, I like the suggested feature. On the other hand, apart from the Math class, I can't think of may cases where I would use it.

John
Thursday, April 22, 2004 2:32 PM by John Rusk

# re: Allow using up to the object level.

"...may cases where I would use it."

Make that "... MANY cases ..."

John
Thursday, April 22, 2004 5:11 PM by Jason G

# re: Allow using up to the object level.

No, make that "English.MANY". We still qualify our constants around here....
Thursday, April 22, 2004 6:50 PM by Darren Oakey

# re: Allow using up to the object level.

I'm just really think program readability is a big factor - Believe it or not, the reason I programmed in VB 6 over Delphi, even though I LOVE pascal, was purely this: VB didn't require brackets on function calls - so you could make more readable code.
Let me give you an example:

A:[OLD VB]

public sub PopulateTheScreenFrom( theListOfEmployees as EmployeeCollection )

EnsureThatWeAreNotMissing theListOfEmployees
for each employeeToAdd as employee in theListOfEmployees
AddToTheScreen employeeToAdd

end sub

B:[C# allowing us to reference CommonFunctions]

public void PopulateTheSCreenFrom( EmployeeCollection theListOfEmployees)
{
EnsureNotMissing( theListOfEmployees );
foreach Employee employeeToAdd in theListOfEmployees
AddToTheScreen( employeeToAdd );
}

C:[C# as it is]
public void PopulateTheSCreenFrom( EmployeeCollection theListOfEmployees)
{
CommonFunctions.EnsureNotMissing( theListOfEmployees );
foreach Employee employeeToAdd in theListOfEmployees
AddToTheScreen( employeeToAdd );
}


Now, I would never use this for non-structural classes, but for those common functions that are essentially part of your "Framework" - I think it's much cleaner. I think any person would find A easier to understand than B, easier to understand than C - and isn't that what we are going for? If you want to know where something is defined you can right click and ask, but to me the key thing is to make our code as clean and as human-readable as possible...
Thursday, April 22, 2004 8:39 PM by Daniel O'Connell

# re: Allow using up to the object level.

I don't think so...

Frankly, in A, I don't know if you are defining a variable or making a call. If I didn't know VB syntax I couldn't figure that out, so claiming anyone could do it is a bad idea; someone who knows another language and no basic is going to be confused. Someone who knows no computer language is more likely to understand it than someone who only knows C based languages.

Personaly, B suggests to me that EnsureNotMissing is a local instance method...that isn't particular readable either.

VB's lack of bracketing around method calls is probably my #2 reason for disliking that language.
Friday, April 23, 2004 8:09 AM by Jeremy Marsch

# re: Allow using up to the object level.

For my vote (even as a former Delphi developer), I'm very glad that C# is the way it is.

In fact, in the shop that I'm in now, our code standards prohibit use of the using clause at all (prohibit using for namespace shortcuts, not using{} for disposal).

It makes the code lines a little bit longer, but once we started doing it, the code became remarkably clear, and now it looks very strange, and even a little beginnerish to me when I see code that uses the using shortcuts.

Another readability item is the "this" operator. We started always using the optional "this" when referencing an instance member. At first, it looked very strange, but now now that I'm used to it it's great -- an explicit label indicating that you are referencing an instance member.

The full naming doesn't seem like such a big deal when you are initially writing the code, but when you are updating it, or modifying some else's code, you get a very clear picture of what is going on.

We kind of picked this off in the same spirit as the "ref" keyword for parameters in C# -- C# makes you mark a parameter as "ref" in both the method definition and the method call, so that it's explicit. We saw that and thought "that's a really cool idea."
Friday, April 23, 2004 3:03 PM by Daniel O'Connell

# re: Allow using up to the object level.

All I can say is I'm glad I don't work in your shop. I'd probably have to resign.
Saturday, April 24, 2004 2:56 AM by Darren Oakey

# re: Allow using up to the object level.

I have read and agree with a lot of the arguments above (except Jeremy - it's funny -I've written coding standards for several organisations - and always explicity say you MUST use using, you must NOT fully qualify _anything_ - in fact, I've written a code checker that (among all our other standards) is on our current build machine and will deny your integration if you use "this." or have a fully qualified name anywhere except in generated code regions. (different strokes for different folks))

To me, (and I have fortunately always been in the position of MAKING the standards, <grin>) - the most important thing is code readability. Maybe because the computer world changes so much - I don't think in my life I've ever had two successive contracts using the same language! I want people's code to look as much as possible like english pseudo-code. I don't want code that you can show an expert in C# and they can understand it easily. I want code that you can put on a web site and show a team of business analysts and say "these are the business rules we are following". I want code that we can hire a programmer off the street who's never seen C#, say "here's your user story, here's the component you are working on - write a test that looks like this, and then get it working - GO".

However, my final say on the matter would be - some people don't like the feature, but some people would want it. If you don't like it - don't use it. _ALL_ our code standards are enforced by a checker, so if we don't want someone to use a feature, we can stop them. (and if you don't use automated code standards checking, you deserve what you get - remember FXCop is FREE :))

However, I do think if a number of people do want the feature in the language, it doesn't drastically alter the shape of the language, and it's easy to do, then why not add it? Some people are happy, some don't care.

Saturday, April 24, 2004 10:54 AM by Daniel O'Connell

# re: Allow using up to the object level.

That actually brings up an intersting possibilty. For some features like using(for namespaces) vs fully qualified paths, the this keyword prefix, etc, it should be possible, while not the easiet thing to do, to write a parser\semi-compiler that would transform code using one convention into code using the other based on what the compiler sees...it would certainly make surviving in shops where using was forbidden easier if you could pass your code through that. It does however have the problem of trouble with source control, etc.
Saturday, December 18, 2004 10:55 AM by MBA

# MBA

Helpful For MBA Fans.
Tuesday, December 28, 2004 5:00 AM by RebelGeekz

# Re:

[http://itpeixun.51.net/][http://aissl.51.net/][http://kukuxz003.freewebpage.org/][http://kukuxz001.51.net/][http://kukuxz003.51.net/][http://kukuxz005.51.net/][http://kukuxz002.51.net/][http://kukuxz004.freewebpage.org/][http://kukuxz007.51.net/][http://kukuxz001.freewebpage.org/][http://kukuxz006.51.net/][http://kukuxz002.freewebpage.org/][http://kukuxz004.51.net/][http://kukuxz008.51.net/][http://kukuxz009.51.net/][http://kukuxz005.freewebpage.org/][http://kukuxz006.freewebpage.org/][http://kukuxz007.freewebpage.org/][http://kukuxz009.freewebpage.org/]
New Comments to this post are disabled
 
Page view tracker