Passing IN parameters

  • Thread starter Thread starter Tal
  • Start date Start date
T

Tal

Is there a way to pass class object to a method in CSharp and be sure that
nothing will change (like writing const in C++).
For example if I have
class testClass
{
int t;
}
testClass tc = new testClass();
tc.t = 99;
And then I'm using it like:
aObj.DoSomething (tc);
I cannot be sure that the t value will not change, although I didn't use ref
or out keywords.
Of course I can copy the tc to another local variable and then sending the
copied object, but if testClass is a huge class, I will pay for it on run
time.
 
Tal,
Theres no way to actually specify the parameter const, but there is no way a
function can change the original variables unless they are passed in by
reference (by adding the keyword "ref") so you're always safe.

Kieran
 
Kieran Benton said:
Theres no way to actually specify the parameter const, but there is no way a
function can change the original variables unless they are passed in by
reference (by adding the keyword "ref") so you're always safe.
Click to expand...

But you're *not* safe. Just because the variable's value itself can't
be changed doesn't mean that the data in the object the variable's
value refers to can't.

For instance, if you pass in an ArrayList reference, the method could
add items to it, or remove them. For an ArrayList, you can pass in a
read-only wrapper, admittedly - but what about an array? You can't pass
or return an array of items without the method/caller (respectively)
being able to change the contents of the array. This means there's a
lot of copying involved in defensive programming.

I believe that const semantics *would* be a very, very good thing - if
they were done properly. However, I believe they'll be very difficult
to design and implement well, both in the CLR and in languages
themselves (the latter in terms of syntax, for example).

There's a modified version of Rotor around with const semantics - I
haven't looked at it yet, but it's good to see that things are
happening. Even if it doesn't solve things particularly nicely itself
(which it may well do) it's something to be pulled apart, so that any
downsides can be addressed.

I'd be surprised if *no-one* at MS is looking at this as a research
issue...
 
Jon said:
But you're *not* safe. Just because the variable's value itself can't
be changed doesn't mean that the data in the object the variable's
value refers to can't.

For instance, if you pass in an ArrayList reference, the method could
add items to it, or remove them. For an ArrayList, you can pass in a
read-only wrapper, admittedly - but what about an array? You can't pass
or return an array of items without the method/caller (respectively)
being able to change the contents of the array. This means there's a
lot of copying involved in defensive programming.

I believe that const semantics *would* be a very, very good thing - if
they were done properly. However, I believe they'll be very difficult
to design and implement well, both in the CLR and in languages
themselves (the latter in terms of syntax, for example).
Click to expand...

David F. Bacon's work on the Guava extensions to Java would be relevent.
http://www.research.ibm.com/people/d/dfb/papers.html#Bacon00Guava has
links to the work in various formats. His real goal was to simplify
multi-threaded programming but to do so, he created ways to gain read-only
access to an object sub-graph.

Bruce Seiler
(e-mail address removed)
 
Back
Top