Passing Objects by ref keyword as a convention

[Deckarep]

Hello fellow C# programmers,

This question is more about general practice and convention so here
goes:

I got into a discussion with a co-worker who insisted that as a general
practice all objects should be passed by reference using the ref
keyword generally speaking because as the writer of code you are
conveying your intentions that an Object should/can be modified by your
function.

For example: public static void ChangePropertyOfObject( ref Obj o )

I actually think that it's wrong to use the 'ref' keyword all the time
because you then allow someone to modify the reference of the object.
So they can potentially create a new object or set the current object
to null.

To me using the ref keyword in everyday code shouldn't be the case and
I don't exactly agree with him. But after a long discussion I'm
actually getting a little unsure of myself.

So what do you guys think? I recognize there are some instances when
using 'ref' keyword may have some benefits but to my knowledge most of
my code that I write doesn't use it and I think it's bad practice to
use it all the time.

Anybody care to help me gain my confidence or am I just flat out the
one who is wrong here?

Thanks guys & gals and happy programming.

-R

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

This question is more about general practice and convention so here
goes:

I got into a discussion with a co-worker who insisted that as a general
practice all objects should be passed by reference using the ref
keyword generally speaking because as the writer of code you are
conveying your intentions that an Object should/can be modified by your
function.

I actually think that it's wrong to use the 'ref' keyword all the time
because you then allow someone to modify the reference of the object.
So they can potentially create a new object or set the current object
to null.

To me using the ref keyword in everyday code shouldn't be the case and
I don't exactly agree with him. But after a long discussion I'm
actually getting a little unsure of myself.

He has misunderstood the ref keyword.

You can modify an object with or without the ref keyword.

The ref keyword allows you to replace the object.

Two completely different things.

And it is certainly not best practice to use the ref keyword
all the time.

I consider it very rare to need it.

Arne

 

[Gary Stephenson]

hi,

I got into a discussion with a co-worker who insisted that as a general
practice all objects should be passed by reference using the ref
keyword generally speaking because as the writer of code you are
conveying your intentions that an Object should/can be modified by your
function.

No - in fact you would be explicitly requiring that the user of your method
_must_ [*1] supply such parameters with the ref modifier included (at the
callsite), thereby allowing your method to modify such reference such that
after the call the calling routine may now have references to entirely
different object(s) than before said call.

Why on earth would you want to go to all that trouble if your didn't in fact
have any requirement to modify the reference itself, as opposed to
manipulating the object it points to.

my $A0.0348,

gary

--
http://www.oxide.net.au

*[1] - Optionality in using 'ref' at the callsite can be provided by
providing an override method without the 'ref' modifier, which simply calls
the original method with the 'ref' modifier supplied. Combinatorial
explosions ensue should there be multiple such parameters.

 

[Jon Shemitz]

I got into a discussion with a co-worker who insisted that as a general
practice all objects should be passed by reference using the ref
keyword generally speaking because as the writer of code you are
conveying your intentions that an Object should/can be modified by your
function.

Your coworker is flat-out wrong. Any class with a writable property
(or a public field) is conveying the intent that users may change its
state. To a lesser degree, public instance methods convey this, too.
If you don't want users to change an object's state, don't provide
property set methods.

For example: public static void ChangePropertyOfObject( ref Obj o )

Fwiw, this makes for bigger, slower code than code that simply passes
(Obj o) by value: all calling code has to include the "ref" keyword,
and what is passed is actually a pointer to a reference, not the
reference itself. This means that every reference to the parameter
within ChangePropertyOfObject is a little bigger and a little slower
than it needs to be.

More importantly, by making every call use the "ref" keyword, you lose
the specialness of passing "ref" parameters. It no longer stands out
when a method call may change the passed parameter.

I actually think that it's wrong to use the 'ref' keyword all the time
because you then allow someone to modify the reference of the object.
So they can potentially create a new object or set the current object
to null.

Exactly. The point of "ref" parameters is not that the call may change
the state of the passed parameter; the point of "ref" parameters is
that the call may change the instance that the caller is pointing to.

 

[Bruce Wood]

Hello fellow C# programmers,

This question is more about general practice and convention so here
goes:

I got into a discussion with a co-worker who insisted that as a general
practice all objects should be passed by reference using the ref
keyword generally speaking because as the writer of code you are
conveying your intentions that an Object should/can be modified by your
function.

Your coworker misunderstands the semantics of parameter passing in
..NET. He may understand the technical details of what "ref" does, but
he doesn't understand the rest of the parameter passing picture enough
to put "ref" in its proper context.

Simply passing an argument of a reference type, Object in your example,
indicates that the caller can change the object's state. That's what
passing a reference by value means: you can change the object's state,
but not replace the object with another object (or with null).

Therefore, by using "ref" all the time, you are _obscuring_ your
intentions: you're pretending that every method may choose to replace
its parameter objects with other objects when in fact that isn't true.

I'm guessing that your coworker's objection to non-"ref" parameter
passing is that simply saying

Object o = ... ;
Foo(o);

doesn't adequately convey that the state of o can be changed, perhaps
as opposed to this:

int i = 3;
Foo(i);

....but if that is his objection then all that that tells me is that he
isn't fully versed in parameter passing conventions in .NET and needs
to read Jon Skeet's article:

http://www.yoda.arachsys.com/csharp/parameters.html

and maybe some others as well.

If my arguments don't convince, then consider the following: the .NET
Framework itself does not use "ref" everywhere. In fact, it uses it
very, very rarely. These are the same people who designed C# and .NET,
and _they're_ not doing this. Therefore, your coworker is claiming that
the Framework designers don't understand parameter passing as well as
he does. The .NET design team isn't _always_ right, but proving that
they're off base in such a huge way is more than anyone I know can pull
off.