|The World According to Nick|
|My take on Software, Technology, Politics, and anything else I feel like talking about.|
Thursday, February 26, 2004
This will probably be my last software rant for a little while... but this is an important one. I posted a couple days ago on how I really wanted a Deterministic Finalizer in .NET... as part of a list of other desired features in C#. One of the other wishes I had was for a construct similar to passing an argument as a const reference in C++.
Why do this? First of all, if my MyClass is large, you don't incur the overhead of creating a new instance of MyClass and copying the contents. However, you also get the safety of passing by value since the foo instance is const (can't be modifed within the scope of the function).
What does C# have? Well... it behaves differently depending on whether the parameter is a value type (int, float, etc.) or a reference type (anything that derives from object). Value types are passed by value by default, so any changes done within the scope of the function are lost. This is good. You can also pass by reference if you wish by placing ref in front of the parameter. This means that any changes made to the parameter are made to the callers version as well. Fine. After all, you specifically declare you wish to have it be reference.
By reference arguments are treated very differently. There is no way to pass by value as above:
So what's the difference between the two. Well, this will illustrate the difference more clearly:
But what if we want to prevent the first case, where the function attempts to change a property... and not overwrite the entire object? You can't. You're only recourse is to implement ICloneable, Clone your object, and pass the Clone to the function, then throw away the Clone. Basically you're doing what a C++ copy constructor does. That can be a lot of overhead for a large object. Not to mention the effort of implementing ICloneable where you normally wouldn't need it.
Why should we care? After all, all you have to do is write your function so you don't modify the object right? Wrong. First of all, what happens if you're using a 3rd party library where you don't have the source? Wouldn't it be nice to have some sort of warm fuzzy feeling when you call that function... knowing that the black box of the library isn't going to do something strange to you? And even if you aren't using a 3rd party library... I like the fact that the compiler is watching my back when I write functions. Declaring my intention to not change a variable and then letting the compiler keep me honest simply reduces possible bugs.
So why is this construct missing? I don't know frankly. I suspect it was an effort to "simplify" the language. But in their effort to simplify things, they've made things a lot less safe... when safety was one of their primary selling points.
Home: Wauwatosa, WI, United States
I'm a Software Consultant in the Milwaukee area. Among various geeky pursuits, I'm also an amateur triathlete, and enjoy rock climbing. I also like to think I'm a political pundit.
View My Profile
Previous PostsO'Reilly Launches WindowsDevCenter.com
I'm Voting for Bush Because Kerry Says He'll Creat...
I Don't Dream of Jeannie... or Why I Hate Wizards
When John Kerry's Courage Went M.I.A.
Security Patches Released For Trillian
FBI Shuts Down Web Host
Democrats Crushing Dissent?
And the Bush/Gore Elections were Undemocratic?
Don't Miss a Sec
Personal LinksCarnival of the Badger
The Coding Monkey
Blog Critics Reviews
Design By maystar