Passing objects to methods then changing the object's state

[hyperD]

Good reading about GOTO statements

Code Complete, First Edition

Very interesting SC - nice one!

[Gentile]

Surely you mean just passing a reference to an object, and not the object itself?

Surely, Shirley?

The trouble is, with Reference Types (e.g., all custom Classes that inherit from System.Object in C#) you are always passing a reference to the object, whether or not you explicitly state that it is by reference.

i.e., the following code will have identical outcomes whether or not you include the highlighted ref keywords. :

namespace DontChangeTheStateOfReferenceObjectsInPublicMethods
{
    class MyClass
    {
        public int SomeIntProperty { get; set; }
    }

    static class MyStaticClass
    {
        public static void MangleMyClass(ref MyClass someClassToBeMangled)
        {
            someClassToBeMangled.SomeIntProperty = 100; 
            //I don't care what it was when you passed this object in
        }
    }

    public class DoStuff
    {
        MyClass myInstanceOfMyClass = new MyClass { SomeIntProperty = 900 }; 
        //I really want this to still be '900' later!

        public DoStuff()
        {
            MyStaticClass.MangleMyClass(ref myInstanceOfMyClass);
            /* myInstanceOfMyClass will be 100 at this point, and I wont 
               be sure why if I don't have access to the code for MyStaticClass.MangleMyClass */
        }    
    }
}

[VectraMan]

void mangle( MyClass& objectToBeMangled )
{
}

void someOtherFunction( const MyClass& objectNotToBeManged )
{
    mangle( objectNotToBeMangled ); // compile error : cannot convert const MyClass& to MyClass&
}

That's how the professionals do it.

Seriously I find it utterly incomprehensible that the forefathers of Java and C# didn't carry this over from C++, as it makes such a difference to the reliability and maintainability of software when you use const types properly.

[Gentile]

void mangle( MyClass& objectToBeMangled )
{
}

void someOtherFunction( const MyClass& objectNotToBeManged )
{
    mangle( objectNotToBeMangled ); // compile error : cannot convert const MyClass& to MyClass&
}

That's how the professionals do it.

Seriously I find it utterly incomprehensible that the forefathers of Java and C# didn't carry this over from C++, as it makes such a difference to the reliability and maintainability of software when you use const types properly.

C# has structs that achieve much the same effect; if 'MyClass' were defined as a struct in my example above (which you could do simply by changing the class keyword to struct), then whether you used the ref keyword or not would affect the outcome.

However, there's a trade-off in terms of memory usage since structs are stored on the Stack rather than on the Managed Heap, and so aren't suitable for .net's Garbage Collection mechanism. In order to benefit from Garbage Collection, you need to rely on developers using Reference Types sensibly.

[VectraMan]

C# has structs that achieve much the same effect; if 'MyClass' were defined as a struct in my example above (which you could do simply by changing the class keyword to struct), then whether you used the ref keyword or not would affect the outcome.

However, there's a trade-off in terms of memory usage since structs are stored on the Stack rather than on the Managed Heap, and so aren't suitable for .net's Garbage Collection mechanism. In order to benefit from Garbage Collection, you need to rely on developers using Reference Types sensibly.

That's not the same effect. You're talking about pass by value, which means a potentially expensive memory copy just to avoid the scenario where the function might change the original data, and wouldn't stop the programmer trying to change the data and spending ages debugging why it wasn't working.

In C++ you pass a constant reference to the object, which means you have limited read-only access to the original object (functions that are marked const), but it's still the original object. Trying to change the object results in a compile error.

The OP's rant was obviously down to spending ages trying to find a bug introduced by some junior programmer. If it had been done in C++, the bug would never have existed because the code wouldn't have compiled.

[Gentile]

That's not the same effect. You're talking about pass by value, which means a potentially expensive memory copy just to avoid the scenario where the function might change the original data, and wouldn't stop the programmer trying to change the data and spending ages debugging why it wasn't working.

In C++ you pass a constant reference to the object, which means you have limited read-only access to the original object (functions that are marked const), but it's still the original object. Trying to change the object results in a compile error.

The OP's rant was obviously down to spending ages trying to find a bug introduced by some junior programmer. If it had been done in C++, the bug would never have existed because the code wouldn't have compiled.

Thanks for that. It's always good to learn a bit more about the capabilities of other languages.

I don't think there's any way to take a readable/writeable object in C# and temporarily make it read only on the fly in the way you described. The nearest I can think of is implementing an interface in the class that renders desired Properties read only such as:



It still relies on the author of the MangleMyClass method taking ownership of the problem, though. I suspect that the OP's problem is caused by an inexperienced developer that is authoring Methods in a way that allows them to be misused.

[BrilloPad]

Why o why are people still doing this and who is teaching these progammers that they are allowed to do this?

Easily the fastest route to a tulipe codebase.

Does my fuggin head in.

</rantOver>

Its deliberate. Obsfucation. The only solution is a good kicking.