[.net] A simple question about get/set.... C# .NET
Author
ok here is a newb question about the new(in C#, im a C++ programmer) get/sets...
say I have:
class SomeFoo;
class Foo
{
private SomeFoo sfFOO = new SomeFoo();
public SomeFoo SomeFOO{ get{ return sfFOO ; } set{ sfFOO = value; } }
}
How do I make sure that when I return sfFOO that they can only SEE it and not change it, sorta like static was used in C++? I know its passing back a reference but I want it to send back a value, or rather a reference but not have it copy or clone and take up double the memory....
So to make things clear, I want them to be able to set it and see it easily but not be able to change it outside of the Foo class.
Sorry for the newb question but I cant seem to find anything on the get/set stuff that dives further in..
Thanks,
Brad
Sorry, I'll not be answering you but I'm having the exact same question here!
I fear that no such protection exists as const member function and const function parameters do not exist in C#. Maybe they destroyed the whole "const object" concept? From my point of view that'd be big a mistake.
Anyways, I'm still curious about the actual answer.
I fear that no such protection exists as const member function and const function parameters do not exist in C#. Maybe they destroyed the whole "const object" concept? From my point of view that'd be big a mistake.
Anyways, I'm still curious about the actual answer.
This MSDN guy says :
I think that this confirms the fact that C# has absolutely no const objects/references mechanism. A documentation page explaining this would still be nice.
Quote:Original text by Eric Gunnerson
My number one biggest desire in C#, or complaint (if you choose)... Are we ever going to see const methods, objects and properties? I'm one of those who basically think languages we should actually be delimiting non-const items, and having everything default to const, but even though there are work-arounds, not having a const specifier I think encourages people (like me) to be lazy and write really dangerous code!
I think that this confirms the fact that C# has absolutely no const objects/references mechanism. A documentation page explaining this would still be nice.
Author
Yea that is very scary. I was just going through writing some code(just started in C#) and am having issues with everything being a reference. It just seems so dangerous when you have to work with other programmers accidently doing something or even yourself making a 3am mistake.
So I would love a way that people can see what I have in my object yet not be able to change the reference in the object itself. The only way I can think of doing it would be to create a new reference and pack it with a clone... which just seems like a massive waste of time and space.
So I would love a way that people can see what I have in my object yet not be able to change the reference in the object itself. The only way I can think of doing it would be to create a new reference and pack it with a clone... which just seems like a massive waste of time and space.
You're overlooking the fact that you have multiple references to the same instance.
The reference returned by the get property is a separate reference to the same instance. If you change the retrieved reference to something else, the original reference inside the class will still point to the original instance.
In your example, I could retrieve a reference to sfFoo, and set that reference to null. However, the reference to sfFoo inside the Foo class is still intact.
In my opinion this makes the const keyword unnecessary.
Additionally, if you don't want the user to alter sfFoo itself by calling member functions, then you shouldn't allow them to retrieve it in the first place. Alternatively, you could also make SomeFoo a struct, which is a value type. Then they'll receive a copy of sfFoo, rather than a reference to it.
The reference returned by the get property is a separate reference to the same instance. If you change the retrieved reference to something else, the original reference inside the class will still point to the original instance.
In your example, I could retrieve a reference to sfFoo, and set that reference to null. However, the reference to sfFoo inside the Foo class is still intact.
In my opinion this makes the const keyword unnecessary.
Additionally, if you don't want the user to alter sfFoo itself by calling member functions, then you shouldn't allow them to retrieve it in the first place. Alternatively, you could also make SomeFoo a struct, which is a value type. Then they'll receive a copy of sfFoo, rather than a reference to it.
Quote:Original post by Alpha_ProgDes
I thought we're supposed to be using properties as opposed to get/set functions....?
I don't understand what you're trying to say here, especially considering that the example described in this thread does use properties...
The problem comes when sfFOO has public methods which you don't want people to call when they access it through the property. Doesn't change the reference, still effects the object.
There's been a few times where I've run across this design desire but I've never much run into the practical problem where I or others modify it. Another thing to keep in mind is that often these sort of patterns occur in a module. Using internal rather than public on SomeFoo's methods will still allow you the access you need while mitigating the possibility for unintended use in such scenarios.
There's been a few times where I've run across this design desire but I've never much run into the practical problem where I or others modify it. Another thing to keep in mind is that often these sort of patterns occur in a module. Using internal rather than public on SomeFoo's methods will still allow you the access you need while mitigating the possibility for unintended use in such scenarios.
pros and cons of good and bad programming aside you could make set private, thus:
class SomeFoo;
class Foo
{
private SomeFoo sfFOO = new SomeFoo();
public SomeFoo SomeFOO{ get{ return sfFOO ; } private set{ sfFOO = value; } }
}
class SomeFoo;
class Foo
{
private SomeFoo sfFOO = new SomeFoo();
public SomeFoo SomeFOO{ get{ return sfFOO ; } private set{ sfFOO = value; } }
}
In java the solution was to create objects that can't be modfyed in any way, to get a modified version the method used to change a value returns clone of it that has the desired fields changed
In c# you can also use structs to accomplish the same thing, structs objects are just like classes objects except anytime you try to copy its reference it clones its self and copys the reference to the new object
In c# you can also use structs to accomplish the same thing, structs objects are just like classes objects except anytime you try to copy its reference it clones its self and copys the reference to the new object
//struct, just like a classstruct Foo{ public Foo(){ num=5; } public int num;}//make new object from Foofoo1 = new Foo();//foo1 is cloned and foo2 gets a reference to the clone, not foo1foo2 =foo1;//this will not change foo1's numfoo2.num=45;//at the end foo1.num == 5 and foo2.num == 45This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
