Passing IN parameters

[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.DoSomethin g (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.

[Kieran Benton]

Re: Passing IN parameters

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

"Tal" <talg@nice.co m> wrote in message
news:%23R9C%234 RdDHA.2732@tk2m sftngp13.phx.gb l...[color=blue]
> 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.DoSomethin g (tc);
> I cannot be sure that the t value will not change, although I didn't use[/color]
ref[color=blue]
> 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.
>
>[/color]

[Jon Skeet]

Re: Passing IN parameters

Kieran Benton <kieranbenton@h otmail.com> wrote:[color=blue]
> 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.[/color]

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 Skeet - <skeet@pobox.co m>

http://www.pobox.com/~skeet/

If replying to the group, please do not mail me too

[Kieran Benton]

Re: Passing IN parameters

Touche Jon :)

Sorry about that, I was obviously misinformed!

Kieran

"Jon Skeet" <skeet@pobox.co m> wrote in message
news:MPG.19c660 312d20340898a4c c@news.microsof t.com...[color=blue]
> Kieran Benton <kieranbenton@h otmail.com> wrote:[color=green]
> > Theres no way to actually specify the parameter const, but there is no[/color][/color]
way a[color=blue][color=green]
> > function can change the original variables unless they are passed in by
> > reference (by adding the keyword "ref") so you're always safe.[/color]
>
> 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 Skeet - <skeet@pobox.co m>
> http://www.pobox.com/~skeet/
> If replying to the group, please do not mail me too[/color]

[Bruce Seiler]

Re: Passing IN parameters

Jon Skeet wrote:[color=blue]
>
> 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).[/color]

David F. Bacon's work on the Guava extensions to Java would be relevent.
http://www.research.ibm.com/people/d...l#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
bseiler@cadence .com